►
From YouTube: 2021 05 11 Jenkins Infra Meeting
Description
Jenkins infrastructure meeting May 11, 2021. Meeting notes at https://hackmd.io/DwlxD9ljRsCY8RxRg88HXA .
Topics included
* LFX Security scanning project
* JEP-229 to increase the security of the Jenkins delivery pipeline
A
Hi
everybody
welcome
for
this
new
jenkins
infrastructure
meeting.
We
we
have
quite
a
lot
of
topics
to
cover
this
meeting,
especially
considering
that
we
had
to
stop
the
meeting
last
week
a
little
bit
earlier.
So
the
first
one
topic
that
I
want
to
bring
here.
We
started
discussing
briefly
last
week,
which
was:
is
it
the
right
time
to
bring
by
confluence
on
the
jenkins
project?
A
A
I
think
here
we
are
trying
to
solve
different
things.
So,
yes,
I'm
really
looking
forward
to
have
your
feedback
on
that
topic.
The
next
topic
that
I
also
want
to
talk
to
cover.
Now
we
had
a
discussion
with,
like
with
the
linux
foundation,
for
an
opportunity
to
use
a
tool
named
lfx.
A
So
lfx
is
an
interface
in
front
of
sneak,
and
so
it's
a
tool
that
we
can
use
to
analyze
security
issues
on
the
project.
So,
by
default
it's
enabled
on
the
jenkins
ci
organization
and
we
have
a
small
group
of
people
who
are
testing
that
and
we
could
also
enable
that
on
the
jenkins
infra
organization,
so
we
have
to
approach
here
either
we
enable
it
on
every
teach
repositories
that
we
have
on
the
jenkins
infrastructure.
A
Are
we
identify
a
small
group
of
repositories
that
we
want
to
analyze
and
based
on
that?
If,
if
everything
goes
well,
maybe
we
could,
I
mean,
extend
the
usage.
I
don't
know
if
you
have
any
expectation
on
this
topic,
I
would
be
really
interested
to
also
hear
about
them.
So
oleg
started
also
a
discussion
on
the
mailing
lists
quite
recently,
so
I
would
be
really
interested
to
have
your
feedback
there
as
well.
A
B
A
B
A
D
A
Yeah,
the
question
was:
how
can
we
integrate
at
fx
security
with
the
jenkins
infrastructure
project?
So
the
idea
here
is:
we
have
around
100
page
repositories.
We
have
different
kind
of
application,
we
also
have
docker
images,
and
so
the
idea
here
would
be
to
identify
a
small
group
of
projects
that
we
could
use
just
to
understand
how
the
process
work
and
how
we
use
that
tool
efficiently.
E
Yeah
yeah,
would
you
do
you
need
a
overview
of
kind
of
what
I'm
hoping
to
do
to
integrate
it
or
if
you
have,
if
you
could
do
a
quick.
A
F
A
F
Okay,
sure,
let
me
is
it
possible
that
I
could
screen
share
with
so
you
should.
Let
me
just
stop
share
my.
E
Okay
sounds
good.
I
will
do
a
quick
thing
here
so
yeah
I
sent
I've
been
sort
of
reaching
out
to
the
community
members
to
discuss
kind
of
what's
involved
with
integrating
lfx
security
version.
Two
you
guys
may
have
seen
the
lfx
security
oops
should
have
came
up
right
security
here
we
go.
You've
probably
maybe
seen
the
v1
system
that
we
have.
E
This
is
our
interface
for
this,
and
if
we
look
for
you
know
just
the
jenkins
or
other
projects
they
happen
to
be
here,
it
provides
sort
of
just
a
roll
up
of
only
vulnerability.
So
this
is
snick.
E
E
This
is
a
tool
called
blue
bracket
which
does
code
secrets.
So
if
I
were
to
log
in
this
is
their
interface,
it's
a
bit
clunky.
So
please
bear
with
me
and
it's
a
bit
slow,
but
we're
going
to
bring
all
the
data
that
they
collect,
as
well
as
the
snick
data
into
our
new
portal.
E
So
if
I
go
back
to
snick
one
of
the
things
that
we're
gonna
inherit
we're
re-architecting
it
where
previously
we
were
scanning
all
the
repositories,
we
were
collecting
all
the
data
and
then
presenting
it
for
version
two
we're
actually
going
to
have
snick
do
the
scans
that
allows
us
to
yeah
their
their
website's
kind
of
bad.
So
sorry
about
that,
but
what
we're
actually
going
to
do
is
snick
is
going
to
be
responsible
for
scanning
the
repositories.
E
That
means
that
we're
going
to
inherit
all
of
their
new
capabilities
that
they've
added
recently,
which
does
include
the
docker
images.
It
includes
net
projects,
things
that
we
haven't
brought
in
to
our
platform.
Yet
so
we're
gonna,
let
them
sort
of
do
all
the
scanning
on
their
side
in
their
infrastructure
and
then
we're
gonna,
actually
just
aggregate
those
results
and
present
it
to
everyone
in
our
portal.
E
E
You
know
any
mistakes
the
developers
have
added
to
the
repository.
That
includes,
like
things
that
are
a
little
suspicious,
it
might
be,
might
be
an
aws
id
might
be
an
aws
token.
Maybe
not
maybe
it's
a
you
know,
credentials
for
a
test
environment,
so
those
are
going
to
be
brought
into
the
console
so
that
the
community
members
and
maintainers
can
review
that
and
then
they
can
make
a
hard
decision.
Whether
or
not
you
know
this
information
is
suspect.
E
You
know
one
of
the
things
we're
gonna
have
to
work
with
this
vendor
is
like
okay,
the
zoom
password.
Is
that
really
like
a
secret?
Is
it
okay
if
we
share
it
with
the
community
in
a
lot
of
cases
like
this
case
here
like
yeah?
It's
fine,
yeah,
just
click
it
and
you
can
come
into
the
zoom
other
cases
where
it'll
help
identify
as
like.
E
If
a
developer
accidentally
included
like
a
terraform
state
file,
which
has
happened,
a
lot
which
happens
to
have
you
know
aws
credentials,
so
those
types
of
things
will
be
brought
in
with
this
tool,
so
we're
hoping
that
we
get
some
feedback
from.
You
know
our
pilot
pilot
projects,
so
you
can
kind
of
see
if
this
tool
is
useful,
is
it
is
it
too
noisy?
Can
we
maybe
tweak
how
we
filter
the
data
such
that
it
brings
awareness?
E
The
other
thing
I
want
to
mention
really
briefly,
and
I
can
pause
it
ask
questions.
Is
this
tool
here
goes
to
the
entire
get
history,
so
if
you
you
may
uncover
or
unearth
a
token
that
was
committed
like
six
months
ago,
perhaps
by
a
developer,
who
has
left
the
project
or
left
the
community.
E
You
can
see
the
vulnerability,
you
can
click
which
will
take
you
and
do
an
sso
log
in
all
the
way
to
the
slit,
the
snick
console
and
then
from
there
you
can
decide
if
you
want
to
create
a
pull
request
to
fix
it
right.
So
maybe
a
lot
of
times
the
vulnerabilities
will
have
a
just
diversion
bump.
That
would
resolve
it.
Maybe
it's
a
node.js
problem,
or
you
know
some
javascript
library
or
a
java.
E
You
know
logger
problem
or
something,
and
maybe
you
just
need
to
bump
the
library
so
we're
going
to
take
you
through
the
through
our
console
over
to
snick
through
sso,
so
you
don't
have
to
log
in
again
and
then
you
can
decide
how
to
fix
it
for
blue
bracket.
We're
going
to
work
with
them
on
how
to
fixing
like
passwords
that
were
committed
six
months
ago
is
a
bit
of
a
problem.
E
You
have
to
actually
go
and
rewrite
a
bunch
of
get
history
if
any
of
you
guys
are
super
familiar
with
that.
That's
a
pain
in
the
butt.
The
last
point
I
want
to
bring
up
about
lfx
security
version.
2
is
given
that
we're
we're
sort
of
pushing
a
new
strategy
for
managing
access
to
your
repositories.
E
So,
instead
of
me
creating
a
personal
access
token,
and
then
me
cloning,
your
project
and
then
me
scanning
your
project
with
my
personal
access
token
and
getting
details
and
querying
the
languages,
and
you
know
the
commit
details
and
all
that
stuff
we're
actually
going
to
be
using
a
github
app,
which
some
of
you
may
be
familiar
with,
and
if
we
part
of
this
is
to
allow
us
to
get
do
this
at
scale.
So
what
happens
is
with
the
github
app
approach?
E
These
are
examples
of
some
of
the
details
that
we
can
access
in
your
org
and
what
we
get
is
like
5,
000
requests
per
org
so
that
for
each
of
the
lf
community
I
can
have
you
know
multiple
instances
of
the
bots
all
over
the
place
and
it
scales
a
little
better
and
I've
enumerated
on
this
one
confluence
page
that
we
have
the
minimum
set
of
restrictions
that
we
think
we
need
in
order
for
the
vendors
blue
bracket
and
snick
to
be
able
to
scan
your
repositories.
E
Yeah,
so
that's
this.
A
big
whirlwind
of
updates
on
the
differences
between
v1
and
v2
security
sounds
like
the
jenkins
infra
project
is
a
smaller
subset
might
be
a
good
candidate.
We
can
choose
one
or
two
repos
to
sort
of
evaluate
this,
but
we
are
looking
for
feedback
and
early
adopters
to
see
if
it's.
If
this
whole
flow
works.
C
Are
there
any
particular
technologist
texts,
you're
focusing
on
because
yeah
the
infrared
repository
has
so
many
different
technologies
due
to
various
historical
reasons?
So
you,
if
there's
something
you
can
feedback
for
particularly.
A
Okay,
so
the
question:
let
me
explain
that
in
different
ways,
so
we
have
quite
a
lot
of
different
git
repositories.
We
have
a
lot
of
different
application,
custom
application.
We
have
terraform,
we
have
helm,
we
have
communities,
we
have
puppet,
we
have.
I
mean
we
have
quite
a
lot
of
stuff
in
the
guild
repositories,
and
so
the
question
was:
is
there
a
specific
project
that
we
should
start
with.
E
Yeah
good
great
point,
good
point.
So,
let's,
let's
talk
about
each
of
our
vendors,
so
one
snick
is
mostly
focused
on
you
know
software
projects
not
not
a
lot
of
ci
cd
like
terraform
and
puppet
and
chef.
E
They
can
probably
look
at
like
chef
and
look
at
the
dependencies.
It
pulls
in
and
then
report.
If
there's
some
known
vulnerabilities
and
maybe
some
network
tools
or
whatever.
So
it's
just
going
to
look
for
dependencies
of
those
tools.
So
if
they're
in
a
manifest
file,
then
those
are
good
candidates
that
snick
can
easily
scan
for
for
blue
bracket
the
code
secrets.
E
It
doesn't
matter
right,
it's
just
looking
for
you
know,
keywords
and
passwords
and
and
things
that
may
have
been
committed
in
your
git
history,
so
it'll
work
regardless
of
the
technology
I
wanted
to
mention.
Also
that
we
are
reaching
out.
We
got
a
demo
last
week.
I
think
there
was
a
a
company
or
a
vendor
that
specifically
was
looking
at
terraform
data,
so
it
was
like
forget
the
vendor
name.
It
was
like
tariff
terraform
state
or
something,
but
they
actually
were
focused
on
applying
policies
to
terraform
to
see.
E
If
you
are
complying
with
best
practices,
so
they
had
like
a
list
of
you
know,
policies
that
you
could
apply
to
a
repository
and
it
would
evaluate
to
see
if
you're
in
compliance
and
of
course
you
can
tweak
the
compliance
stuff,
but
it
actually
had
a
lot
of
intelligence
on
you
know.
How
are
you
using
ec2,
you
know
and
and
all
the
other
aws
resources
and
ours
is
sort
of
the
best
way
of
going,
so
it
make
recommendations
so
longer
term.
E
That's
what
we're
also
hoping
to
bring
in
more
ci
cd
infrastructure
tools
within
this
platform.
A
Okay,
that
sounds
great,
but
we
also
have
custom
applications.
Let's
say
you
know
the
accounts
app
and
stuff
like
that,
so
we
definitely
I
mean
we
definitely
have
places
where
we
can.
We
could
test
and
learn
a
little
bit
pizza
too.
A
Regarding
the
gita
app
app,
I
think
what
we
can
do
with
for
the
next
step
would
just
be
to
allow
a
specific
key
repository.
So
not
the
whole
organization,
but
just
let's
say
five,
absolutely
yeah.
In
that
case,
would
it
be
possible
to
have
access
to
the
documentation
that
you
just
show
about
the
permission
that
you
need.
E
Yeah,
I
have
so
when
you,
when
you
click
on
the
app,
so
what
I
would
probably
do
is
just
agree
with
you
like
how
many
repos
you
want
to
bring
on
board
step.
One
for
me
is
to
just
set
it
in
my.
I
basically
on
board
it
and
add
some
entries
in
my
database
step
two
is:
I
will
give
you
a
link
to
the
github
bot.
You
click
on
it.
You
decide
if
you
want
all
the
reposes,
like
you
said,
or
just
a
subset.
E
A
E
E
And
then
so
I
I've
I've
reached
out
to
the
vendors
and
it's
like,
I
think
this
is
the
minimum
set,
so
I'm
sort
of
also
negotiating
with
them
was
like.
Can
you
confirm,
like
the
links
I'll
share
with
you,
an
email?
If
you
give,
if
we
do
that
I've
hyperlinked
the
exact
api
calls
that
are
going
to
be
invoked
for
like
reading
the
email
or
doing
a
web
hook,
there's
actually
a
very
specific
list
of
api
calls
that
are.
Are
there
so
yeah?
E
You
can
review
that
and
decide
if
it's
something
that
you're
comfortable
with
or
not.
E
Yeah,
so
you
just
choose
like
when
you
set
it
up,
you
can
just
you,
can
select
or
do
all
yeah.
E
We're
obviously
looking
for
feedback
on
the
security
tool
and
the
experience
ideally,
instead
of
me
and
you
talking
you
could
we
would
direct
you
to
our
console
and
then
you
could.
We
would
give
you
permission,
you
could
review
it
all
point.
Click
point
click
and
just
do
it
yourself,
but
it's
a
little
early
phases
we're
trying
to
get
the
admin
console
going
yeah
for
now,
we'll
just
do
it
this
way.
A
E
We
have
our
developers
are
working
on
the,
for
example,
the
blue
bracket
representation.
So
all
the
data
that's
coming
back,
he's
drawn
he's
taken
that
api
from
the
blue
bracket
and
displaying
it.
So
I
think
in
the
next
coming
weeks
we're
going
to
be
adding
that
and
so
for
you
guys
who
have
onboarded.
I
want
to
show
that
to
you
at
some
point
and
get
you
to
start
looking
at
it
and
then
that's
where
I
think
you
guys
can
come
back
and
say:
oh,
this
is
this
is
good.
E
E
Yeah,
so
should
I
drop
now
or
should
I.
A
Mainly,
I
think
if
we
don't
have
another
question,
you
can
drop
if
you
like,
otherwise
you
can
stay
with
us
as
you
wish.
We
can.
We
we
just
talked
about
specific
topics
for
the
jinkins
infrastructure,
so
feel
free
to
drop
off.
If
you
prefer.
Okay,
thanks.
C
Bye,
thank
you
so
yeah
regarding
the
infrastructure
actually
wanted
to
ask
what
additional
permissions
agreements
we
need
to
start
today.
I'm
understanding
that
olivier
prefers
to
go
ahead
and
try
out
some
repositories
and
as
long
as
we
protect
confidential
content
within
the
jenkins
central
organization,
I
think
we
could
do
that.
A
A
So
now
the
question
is
what,
because
my
understanding
is,
the
v2
is
not
really
yet
so
we
only
have
access
to
the
sneak
yeah,
so
sneak,
and
so
in
that
case
it
sounds
to
me
that
analyzing
docker
images
is
maybe
better.
C
So
I'm
not
sure
whether
it
will
work
same
for
the
most
of
them
jenkins
organization.
We
are
waiting
for
way
to
specify,
allow
lists
and
analysis
for
cvs
before
that
it
doesn't
make
sense
to
adopt
security
in
the
main
organization
and
we
are
waiting
for
sneak
to
deliver
the
future
protesting.
C
A
A
G
C
B
G
A
And
if
we
want
to
go
one
step
further,
we
could
also
analyze
the
jenkins
cell
test
or
the
jenkins
weekly
docker
image,
because
it's
a
simple
docker
file
and
we
have
a
double
advantage
there,
because
we
may
catch
a
horse
from
the
jenkins
upstream
that
we
maintain
as
well.
So
I
think,
by
carefully
taking
selecting
the
right
hip
repositories,
we
could
also
have
that
could
also
benefit
to
the
jki
organization.
G
C
Yeah
david
is
ready
to
create
a
new
organization
for
us
because
of
the
specifics
of
standard
integration
that
you
can
have
one
github
integration
to
one
single
organization,
and
basically
it
means
just
having
one
hot
work.
Of
course,
I
do
not
think
that
it's
any
kind
of
concern,
because
there
will
be
little
to
no
overlap
between
central
engineering
ti
in
terms
of
configurations,
so
I
think
that
we
could
start
drinking
some
translucents
and
then
figure
out
the
rest
later.
A
And
something
that
I'm
wondering,
if
it
would
benefit
is
to
analyze
repositories
like
the
plugin
site,
api
or
jenkins
website,
because
in
those
git
repositories
my
understanding
is.
We
are
more
interested
by
our
credentials
that
we
would
like,
or
something
like
that.
C
C
So
for
me,
it
would
be
useful
to
just
to
get
as
many
projects
as
we
can
relatively
safely
and
get
some
results
to
see
whether
it
produces
complete
crop
or
whether
it
produces
something
potentially
feasible
for
this
type
of
repositories
and
then
iterate
based
on
that,
because,
for
example,
if
it
produces,
let's
say
five
warnings
for
plug
inside
and
this
warnings
are
reasonable.
Just
for
dependable
to
pick
up.
Okay,
great,
this
tool
works,
let's
keep
it
if
it
produces.
Ten
thousand
fails
positives
so
like
for
junkies
plugins.
A
So
it
sounds
like
we
have
kind
of
an
agreement
that
we
are
all
interested
to
move
forward.
Another
question
is:
who
will
drive
that
project?
We
don't
have
to
take
a
decision
right
now,
but
I
think
that
would
be
a
nice
opportunity
if
someone
is
interested
to
know
it
a
bit
more.
Obviously
because
of
the
topic,
I
would
prefer
to
have
someone
familiar
with
the
jenkins
project,
but
I
think
that
would
be
a
great
opportunity
to
delegate
a
little
bit.
C
D
D
Recently
and
tried
evaluating
before
and
it
just
didn't
fit
for
us,
I
logged
into
it
basically
and
it
opened
200
pull
requests
under
my
account
and
just
completely
spammed
my
inbox.
I
had
to
write
a
script
to
close
them
all
it
was.
It
was
horrible.
Well,
I
didn't
literally
write
java
code
to
do
it,
so
I
couldn't
find
any
bulk
way.
There's
no
bulk
way
to
close
pull
requests
and
getting
notifications
constantly.
C
A
On
that,
on
that,
on
that
noise
topic,
where
I'm
really
afraid,
I'm
really
afraid
that
it
analyzed
the
old
history
of
the
jenkins
infrastructure
to
detect
passwords
that
were
leaked
and
stuff.
Like
that,
I
mean
we
modified
that
yeah.
We.
D
C
D
A
A
Okay,
I
was
keeping
that
news
for
once
we
have
more
information.
You.
A
I
can
say:
okay
thanks
thanks
alec
for
starting,
so
alex
oleg
contacted
amazon
to
see
if
we
could
renew
the
sponsoring
program
and
it
seems
to
be
good
but
yeah
we
still
have
to
to
solve
and
to
to
fill
some
paper.
D
On
the
one
note
on
the
egypt
229,
I've
got
a
progress
on
jenkins.io
documenting
and
recommending
the
jet
229
process
for
automating
the
plugin
releases,
moving
away
from
people
releasing
from
their
laptops.
I
think
daniel
raised
a
concern
that
it's
more
pressure
on
infrastructure
and
I
kind
of
documented
two
processes
where,
if
different
levels
of
infrastructure
are
down,
you
can
work
around
it
see
any
concerns
about
the
recommendation.
C
I
do
have
concerns.
We
still
have
a
problem
with
releasing
jenkins
components,
not
from
jenkins.
So
basically
we
say
that
if
you
use
want
to
do
continuous
delivery
for
components,
we
would
rather
use
github
actions
than
jenkins.
I
understand
that
it's
not
exactly
what
we
say,
but
it
can
be
perceived
that
way
and
before
we
recommend
the
job
229
process.
I
think
that
we
need
to
explicitly
agree
on
that.
So
we
had
discussions
at
the
contributor
summit,
but
I
believe
they
were
inconclusive
so
far.
A
My
understanding
is
that
would
be
difficult
to
use
jenkins
instead
of
getting
action,
so
I
definitely
share
your
concern.
I
would
also
prefer
to
jenkins
instead
of
get
action.
C
C
Multiple
ways
we
can
keep,
let's
say,
jump
to
9
in
preview
for
now,
until
we
totally
upgrade
that
it's
something
we
want
to
wider
the
adult.
In
this
case,
we
keep
this
topic
down
the
road.
At
the
same
time,
we
don't
get
quite
adoption
of
the
process
for
now
or
we
do
opposite.
We
say
that
now.
Github
actions
is
the
future
for
continuous
delivery
of
jenkins
components
and
and
yeah.
Probably
it
gets
a
wider
adoption
but
yeah.
It
sounds
a
bit
weird
to
be
honest,.
A
What
I
find
weird
is,
I
don't
think,
that's
a
topic
that
we
should
cover
in
the
jenkins
super
meeting,
because
it
I
mean
it.
A
Decision
yeah,
I
agree,
definitely
because
what
we
can
do
in
the
jenkins
enforcer
infrastructure
meeting
is
to
identify
ways
to
improve
and
to
help.
So
if
you
want
to
move
forward
and
implement
a
reuse,
chep
209
and
we
have
dependencies
on
infrastructure,
maybe
we
can
improve
it
in
the
monitoring
house,
I
mean
those
are
kind
of
things
that
we
should
discuss
on
the
jenkins
infra.
I
definitely
not
about
to
definitely
get
the
documentation.
C
From
him
merged
to
put
a
work
in
progress,
preview
notice
for
now
to
have
it
listed
from
the
navigation
as
preview,
but
not
to
switch
it
to
the
default
recommendation
for
now
until
we
reach
the
agreement.
Thank
you.
D
I
don't
know,
I
don't
think
it's
a
government
support
thing.
It's
a
part
of
the
jet
process
and
mailing
in
the
mailing
list,
thing
yeah.
So
it's
not
governance.
C
D
C
A
C
A
So
yeah
on
my
side,
I
just
prefer
to
move
step
by
step.
So
if
we
already
have
something
working,
we
could
also
improve
the
situation
later,
but
yeah
again,
I
propose
that
we
because
we
are
forming
over
the
meeting.
So
I
propose,
as
you
stop
the
meeting
here
and
that
we
continue
the
discussion
on
the
mailing
list.