►
From YouTube: SLSA Tooling Meeting (May 26, 2023)
Description
Meeting notes: https://docs.google.com/document/d/15Xp8-0Ff_BPg_LMKr1RIKtwAavXGdrgb1BoX4Cl2bE4/edit#heading=h.yfiy9b23vayj
B
D
B
I
feel
like
we
probably
ought
to
do
some
Outreach
so
that
people
know
this
is
a
place
they
should
come
about
and
talk
about,
theirselves
or
tooling.
I,
don't
know
that
they
do
whether
they
have
developed
something
or
they're
working
on
something
or
they
they
are
looking
for
something
you
I
mean
come
on.
It's
always
the
same
like
what
four
or
five
people
yeah,
but
you
know
what
I'm
saying
is
yep
there's
got
to
be
more
than
that
happening.
We
just
don't
see
it.
The
people
are
not
coming
here,
so
I
I
think
it's
unfortunate.
C
Yes,
no
and
and
definitely
could
use
some
help
on
that,
one
from
from
anybody
who
might
be
able
to
help
their
help
promote
the
you
know,
because
I've
been
talking
on
my
end.
I
know.
A
lot
of
folks
who
are
working
on
the
you
know
on
the
west
coast
are
doing
a
lot
of
stuff
on
in
Asia
or
doing
a
lot
of
stuff
on
the
salsa
side.
C
I
know
I
actually
have
a
meeting
next
week
with
some
of
the
folks
in
APAC
who
are
looking
to
do
stuff
on
salsa,
but
as
far
as
folks
sort
of
Europe
and
us
I'm
I'm,
not
super
sure
of
who's.
Working
on
what
I
mean
I
know
I'm
working
on
salsa
related
tools,
but
but
I'm
not
sure
about
other
folks
who
are
working
on
salsa,
related
tools
of
the
open
source
space.
B
Maybe
we
should
enroll
like
like
Jennifer
from
the
staff,
to
help
us
with
a
bit
of
communication
here,
I,
don't
know,
but
especially
after
salsa
one
zero,
you
know
getting
released.
You
would
think
that
people
looking
into
okay.
What
does
it
mean
and
they
should
be
the
place
they
come
for
questions
and
what
tools
to
use
or
what
tools
they're
working
on.
C
D
D
If
not,
you
know
directly
in
some
of
our
CI
internally
to
the
company,
and
so
you
know
I'm
looking
around
to
see
you
know
what
what
the
community
is
implementing
on
right,
GitHub
actions
is
obviously
popular.
Tech
Don
seems,
you
know,
is
another
one
that
I
see
prototypes
on
there's.
Actually
somebody
I
work
with
in
Intel.
That's
part
of
that
tecton
prototypes.
D
C
But
a
lot
of
folks
have
said:
I
don't
know
if
Jenkins
is
worth
salsifying
because
it
might
just
be
a
ridiculous
amount
of
effort
that
would
require
folks
to
redeploy
all
of
their
infrastructure
that
they're
using
for
Jenkins
anyway,
in
order
to
sort
of
implement.
You
know
some
of
the
basic
security
features
that
that
that
you
would
need,
but
there
are
folks
who
are
looking
to
perhaps
maybe
sidestep
the
problem.
I
know
we're
we're
looking
at
that.
C
At
my
you
know,
company
we're
looking
to
potentially
build
some
tools
that
sidestep
this,
and
this
would
be
in
the
open
source
space,
but
we're
working
with
some
stuff.
First.
That
would
include
just
essentially
saying
having
your
Jenkins
jobs.
Call
a
separate,
secure,
build
service
right
because
a
lot
of
folks
who
are
using
Jenkins
they're,
not
just
using
it
purely
for
compilation-
and
you
know,
packaging
they're
using
it
for
compilation,
packaging,
QA
tests
deployments
to
QA.
C
You
know
to
to
different
environments
they're
using
it
for
like
a
million
things
and
salsa
is
very,
very
much
focused
on
the
build
and
packaging
step,
and
so,
if
we
can
kind
of
maybe
sidestep
that
and
say
hey
here
is
a
separate,
almost
small.
You
know
not
quite
CI
system,
but
a
smaller
system
that
can
just
focus
on
QA
that
can
focus
sorry
not
on
QA
and
any
of
those
other
things,
but
Focus
purely
on
the
build
and
packaging
that
might
be
something
to
get
at
least
some
salsa
in
your
Jenkins
environment.
D
The
solution
probably
needed
to
be,
which
is
you
know,
a
Jenkins
with
a
very
specific
lockdown
set
of
plugins,
and
you
don't
get
to
change
those
and
you
probably
don't
get
to
configure
them
either,
and
you
know
just
all
these
restrictions
that
severely
change
the
way
people
use
Jenkins
now
you
know,
but
you
know
possibly,
you
know
that
that's
you
know
like
you
were
saying
that
that
comes
down
to
in
those
build
phases.
They
have
to
use
that
configuration,
but
elsewhere.
D
C
Yeah
also
I
guess
the
meeting
is
going
on,
because
I
actually
have
a
bunch
of
thoughts
around
this.
We
could
probably
write
something
up,
even
maybe
make
it
into
something
so
feel
free
to
for
folks
who
want
to
stick
on
and
and
chat
about.
This
feel
free
to
put
your
sort
of
name
in
in
here,
but
the
yeah.
C
So
there's
a
couple
things
one
is
we
found
and
I
don't
remember
exactly
when
this
was,
but
we
we
have
been
trying
to
talk
to
folks
from
the
sort
of
Jenkins
side
of
things
around
securing
it
and
around
making
it.
You
know,
essentially
what
you
were
saying
and
so
obviously
there's
two
problems.
One
is
the
reason
why
a
lot
of
folks
don't
want
to
move
off
of
Jenkins
is
because
hey
they
have
all
this
Legacy
stuff.
C
They
are
using
all
these
other
plugins
and
yada
yada,
and
so
when
somebody
comes
in
and
says
hey,
we
can
secure
your
Jenkins
as
long
as
you
completely
redeploy.
A
completely
different
Jenkins
is
is
is,
is
is
not
always
helpful
in
those
situations
because,
obviously
hey
if
I
was
doing
that,
then
why
would
I
I?
Wouldn't
necessarily
need
to
keep
going
with
Jenkins,
except
for
to
say
you
know,
I'm
knowledgeable
with
Jenkins
or
something
like
that.
C
But
one
of
the
things
we've
been
pointed
to
is:
there's
a
you
know:
a
tool
called
Jenkins
X
Jenkins
X
is
tecton
based
and
folks,
saying
hey
the
Jenkins
that
Jenkins
X
is
is
more
of,
like
you
know
the
quote-unquote,
secure,
Jenkins
and
and
that
sort
of
thing,
but
obviously
that
lead
that's
still
the
same
problem.
If
folks
don't
want
to
move
off
of
their
existing
infrastructure,
then
they're
not
going
to
want
to
move
off
of
Jenkins
to
a
like
something
like
tecton
through
check.
C
You
know
Jenkins
X,
and
it's
that
and
to
be
clear.
This
is
the
same
thing
we're
seeing
with
you
know.
Inside
of
openssf,
there's
a
project
called
you
know:
Fresca,
which
uses
tecton
tecton
chains,
spitney
Spire
love
from
a
lot
of
folks.
It's
like
hey,
I,
I,
there's
a
lot
of
things
here.
I
have
a
Jenkins.
C
Yeah
you're,
not
you
know,
you're
still,
you
know
potentially
there's
issues
with
with
QA
and
you
know
whatever
else
you
might
be
doing,
but
the
the
build
piece
is.
You
know
the
one.
That's
running
arbitrary
code
execution
potentially,
so
if
you
can
secure
that,
you
know
you're
you're,
eliminating
a
bunch
of
stuff
and
if
you
can
kind
of
take
that
out
of
the
hands
of
Jenkins,
that
might
be
good
enough
for
some
folks.
D
Right
yeah
I
mean
there's,
there's
some
effort
to
move.
People
into
you
know
have
their
their
Runners.
All
you
know
running
in
kubernetes
instances
and
you
know,
and
so
on,
and
you
know
same
thing
actually
for
GitHub
actions
is
the
other
side
that
we
use.
But
you
know
due
to
security
policy.
You
know
it's
all
internal
Runners
and
so
there's
you
know
some
effort
bringing
up.
You
know
kubernetes-based
Runners
for
that
right
and
and
that's
working
and
it's
it's
relatively
painless
to
go
from.
D
You
know
external
stuff
to
internal,
but
yeah
Jenkins,
just
figuring
out
how
to
secure
the
controller,
let
alone
you
know,
adapt
the
the
typical
way
that
people
seem
to
connect
their
Runners
to
Jenkins.
So
it's
yeah,
it's
all
all
something
we're
trying
to
solve
and
I'm
trying
to
find
as
many
experts
that
are
willing
to
help
me
but
yeah
at
this
point
it's
it's
hard
to
find
people
with
time
or
even
the
motivation
to
change
the
way
they
work
right.
As
you
mentioned,.
C
C
The
you
know,
without
getting
into
too
many
you
know
like
without
it
yeah
motivating
people
to
spend
time
trying
to
secure
Jenkins
is
always
going
to
be
hard
yeah
that
that's
that's
one
big
issue
and
then
like
there's
a
lot
of
folks
who
you
know
I
I
was
at
a
devops
Meetup
yesterday,
where
you
know
one
of
the
things
that
was
talked
about
was.
Is
it
worth
the
you
know
even
within
an
organization?
C
Is
it
worth
the
time
and
effort
to
secure
something
that
you
know
is
kind
of
like
insecure
by
default?
You
know,
by
the
time
you've
figured
out
all
the
right
ways
to
run
it
and
yayada.
It's
like
you've
already
done
enough
work
to
move
off
of
Jenkins
or
or
more
than
enough
work
to
move
off
of
it
in
the
first
place.
C
C
You
know
we
had
a
lot
of
the
secure
jobs
that
had
to
run
ran
like
you
know,
Jenkins
would
call
something
else
and
that
something
else
was
locked
down,
and
so
that
would
be
the
thing
that
actually
ran
those
secure,
builds
and
not
Jenkins
itself,
but
Jenkins
could
still
be
used
for
all
the
additional
orchestration
like
pulling
down.
You
know,
tests
and
running
them
and-
and
you
know,
deploying
to
different
environments-
and
you
know
all
that
sort
of
stuff.
D
People
from
you
know
just
running
their
own
Jenkins
controllers
and
you
know
random,
Labs
or
under
their
desks
or
you
know
whatever
the
the
the
typical
history
has
been
to
it
hosted
Runners
right
and
you
know
it's
all
a
you
know:
Cloud
bees,
Jenkins
and
you
know
so
on,
and
so
there
there
is
a
little
bit
of
work
that
needs
to
be
done
to
move
from
one
environment
to
the
other,
just
in
reprovisioning
and
everything
else.
Of
course.
D
Now,
once
you
go
into
I.T
and
they're
running
these
Runners
and
and
kubernetes
instance,
instead
of
on
their
their
own
machine
and
all
that
kind
of
stuff
where
teams
are
used
to
having
these
controllers
with
with
you
know,
32
cores
and
gigs
and
gigs
of
RAM
and
they're
doing
all
this
processing
and
custom
plugins
and
all
this
kind
of
stuff.
It's
like
you
know,
look
you're,
you're
killing
us.
You
need
to
move
this
workload
out
to
your
runners,
and
so
you
know
just
looking
at
what
it
is
requesting
that
people
do.
D
You
know
for
the
good
of
the
entire
system
and
stability
of
that.
You
know
it's
kind
of
one
of
those
points
where
you
know
like
you're
saying
people
are
gonna
have
to
change
the
way
they
do
a
lot
of
things,
and
so
we
can
possibly
capture
them
right
and
and
cause
some
other
changes
in
the
way
they
use
it,
and
so
so
yeah.
If
there's,
if
there's
a
yeah
I
guess
the
my
you
know
my
initial
thing
to
see.
If
there
were
other
Jenkins
users,
I
mean
if
they're.
D
A
C
Yeah
yeah,
so
most
likely
Jenkins
could
hit
level
two
as
long
as
you
had
a
mechanism
in
the
plug-in
to
actually
do
signing
so
level.
Three
is
definitely
a
bit
of
a
stretch
and
would
probably
require
a
good
deal
of
you
know
looking
at
Jenkins
to
see
how
that
might
be
possible
and,
in
fact,
I
believe,
there's
a
couple
of
plugins
one
one
plug-in
is
under
the
salsa
framework.
It
was
contributed
to
us
by
Samsung.
C
The
problem
is
that
once
they
contributed
it,
nobody
has
continued
to
maintain
it
and
and
for
a
lot
of
folks.
You
know
a
lot
of
us,
don't
really
know
or
use
Jenkins
anymore.
So
so
we're
not
super
familiar
with
how
to
sort
of
maintain
that
plug-in
and
maybe
try
and
see
if
it'll
get
up
to
the
next
level.
D
C
C
C
Well,
so
you
need
to
have
some
way
of
doing
the
signing
like,
and
so
you
could
have
something.
That's
like
different
steps
outside
of
the
the
end
user
control.
Probably
maybe
you
know
like
there's
probably
some
way
you
can.
You
can
still
do
that
without
the
plug-in,
but
the
plugin
just
makes
it
I
guess
easier.
D
D
A
I
think
that
a
feature
like
that
would
be
awesome
not
only
for
Jenkins
but
like
across
the
board,
any
Builder
that
does
not
comply
to
start.
Second,
like
one
I,
don't
know
like
a
Docker
compose
or
whatever
you
imagine
and
and
build
this
above
a
system
above
it,
okay,
I
think
it's
a
very
useful
tool
even
locally
to
try
it.
You
know.
D
So
now,
in
an
environment
where
you
have
a
kubernetes
cluster,
doing
your
runners
says:
Jenkins
plus
you
know
admittedly
I.
Don't
know
enough
about
tecton
to
talk
super
intelligently
about
it,
but
would
combining
a
Jenkins
with
tecton,
where
tecton's
your
Runner
I
mean
you're
kind
of
doubling
up
on
your
your
infrastructure.
There
I
guess,
but.
C
Yes,
so
that
could
definitely
work
I
think
most
folks
would
probably
want
something
simpler
right,
like
most
folks,
are
not
going
to
want
to
probably
say
Hey.
You
know,
because
because
the
folks
who
who
you
know
once
again
not
everybody-
wants
to
move
on,
but
Jenkins
yeah
yeah,
but
also
then
a
lot
of
folks
are
like
hey
I,
don't
want
to
necessarily
especially
for
people
who
don't
aren't
using
Cloud
native
one
second
year.
C
C
So
that's
a
that's
a
concern,
and
so
I
was
actually
thinking.
You
know
based
on
like
if
you
look
at,
for
example,
there's
like
build
packs
and
there's
all
these
other
things
that
are
out
there.
Could
you
leverage
something
like
you
know,
and
this
is
you
know,
maybe
playing
a
little.
You
know
putting
it
out
there
like
some
folk.
You
know
some
folks
like
myself
are
looking
at.
Could
you
use
micro,
VMS
or
something
like
that
anywhere?
C
C
Whatever
this
thing
is
Will
spin
up
the
micro,
VM
it'll
run
the
build
it'll
run,
the
compilation
it'll
do
whatever,
but
it'll
do
it
and
then
also
do
all
the
there'll
be
a
wrapper
around
that
that
does
the
signing
and
all
that
stuff
and
so
that
it's
kind
of
this
little
encapsulated
thing.
That
would
be,
you
know,
maybe
one
minor.
You
know
Damon
that
runs
on
a
machine
plus.
C
You
know
the
ability
to
spin
up
these
micro
VMS
right
some
code
to
spin
up
those
things,
and
then
everything
else
is
essentially
the
same
as
your
normal
build
I
wonder.
If
that's
you
know,
there
seem
to
be
some
folks
poking
around
that
sort
of
idea.
So,
as
opposed
to
spinning
up
a
whole
thing,
you
just
sort
of
say:
hey
I
run
this
thing
on
my
Runners
and
that
thing
does
this
extra
stuff,
something
like
that.
D
C
So
you
end
up
with
situations
where
one
build
could
potentially
see
the
output
of
other
builds,
which
is
or
or
inputs
of
other
builds
and
start
to
mess
with
other
builds,
and
that
sort
of
thing
makes
it
impossible
to
do
salsa
or
at
least
salsa
level.
Three
or
maybe.
If
it's
also
level
two
I
have
to
double
check
that
it's.
D
Set
up
a
machine-
and
you
know
it's
all
over-
you
know
bad
habits
up
here,
so
yep
yeah
we're
trying
to
cut
that
off
before
it
gets
too
heavily
ingrained,
but
yeah.
It's
as
you
can
imagine
you
know.
Intel
is
a
big
company
and
so
you're
you're,
always
finding
somebody
with
a
new
CI
that
you're
trying
to
you
know
bring
into
the
fold.
So.
C
Yeah
yeah,
and
so
there
is
that
sort
of
problem,
and
how
do
you
kind
of
you
know
so
there
has
to
be
some
something
like
that
you
know,
and
so,
if
we
look
at
some
of
the
other
stuff
white
with
Jenkins,
you
know
the
plug-ins
right.
The
plugins
can
potentially
see
whatever
anything
on
any
of
the
other
plugins
look
at
and
there's
not
really
a
great
mechanism.
Within
Jenkins
for
like
capabilities
right
where
you
could
say
hey
this
plug-in,
is
a
security
plug-in.
C
D
There's
no
sandboxes
yeah
yeah
yeah,
that's
my
concern
with
all
the
plugins,
and
you
know
that
you
know
because
Jenkins
is
so
flexible,
which
is
you
know
great
for
what
a
lot
of
people
want
to
use
it
for
that's
why
they
use
it
right.
But
sometimes
you
know
you
see
the
custom
plugins,
that
teams
build
and
they're
doing
serious,
computation
and
and
a
lot
of
what
you
would
consider
the
Builder
stage
actually
in
plugins,
and
you
know
just
the
way
they
use
the
Jenkins
controller
storage
and
things
like
that.
D
That
has
you
know
Mass
potential
to
stomp
on
things
right
and
interfere
with
each
other's
builds.
If,
if
something
kicks
off
at
the
wrong
times
and
and
then
they
use
a
plug-in
to
make
sure
that
they
don't
run
at
the
same
time
and
I
mean
it
just
it
it's,
you
know,
plugins
all
the
way
down
right
and
so
so
yeah.
Those
are
you
know
again.
You
know
the
culture
of
usage
that
would
need
to
be
dealt
with.
C
Obviously
you
know
a
lot
of
folks
who
are
going
to
be
like
hey
I
I
run
my
you
know,
I
run
my
build,
but
then
my
build
kicks
off,
QA
and
and
kicks
off
all
these
other
things.
And
so,
even
though
my
build,
maybe
is
something
like
Maven
build
or
or
you
know,
just
running
make
that
just
calls
GCC
or
something
beyond
that.
You
know,
there's
a
million
other
steps
to
then
say:
okay.
C
You
know
the
build
the
build
sure,
but
everything
else
I
can't,
and
so
that's
kind
of
where
you
know
a
lot
of
folks
have
been
asking
about
like
something
like
a
very
minimal
CI
right,
but
not
actually
CI.
Just
a
very
minimal
build
system
that
all
it
can
do
is
take
requests
to
run,
build
and
packaging,
because
once
again,
that's
where
salsa
comes
in
mostly
right.
You
can
technically
salsify
your
entire.
You
know
pipeline,
but
that's
really
not
the
core
intent
and
that's
not
where
you
get
the
majority
of
the
benefit.
C
The
majority
of
the
benefit
is
mostly
in
that,
like
I've
looked
at
the
inputs
and
I
recorded
it
I
looked
at
what
you
did
in
the
build
and
recorded
it
and
I
looked
at
what
the
output
was
and
recorded
it.
So
if
somebody
else
reports
something
different,
something's
gone
wrong,
you
know.
So
if
you
publish
whatever
something
with
hash
X
and
something
comes
out
with
hash
y,
you
know
that
you
know
something
has
tried
to
compromise
it.
C
E
D
Make
sure
you
know
every
time
I
have
a
conversation
about
salsa
and,
of
course
it
blows
up.
You're
gonna
make
me
change.
You
know
what
you
know.
What
the
then
the
immediate
question,
which
every
engineer
asks
when
they
don't
want
to
do,
work,
which
is
what's
the
business
value,
is
you
know
of
of
you
know?
D
Why
are
you
going
to
make
me
do
this
right,
but
you
know
you're
pushing
through
that
to
make
sure
you
know
some
of
the
the
uphill
battle
can
be
solved
by
making
sure
the
messaging
is
there
that
they
only
need
to
really
worry
about
this
on
their
their
build
controller,
because
you
know
we,
like
you,
said
people
are
using
it
for
everything.
You
know
deployment
across
everything
through
testing
and
whatever,
and
so
you
can
imagine
you
know.
E
You
know
p2m
sort
of
like
doing
all
that
automated
testing
and,
like
you
know,
you're
totally.
You
know
breaking
outside
the
infrastructure
running
tests
out
there
and
then
coming
back
in
with
the
results
at
the
end
and
like
that,
you
know
you
can't
not
do
that,
because
you
can't
really
reasonably
run
a
Jenkins
runner
on
the
on
the
embedded
controller
that
you're
trying
to
test.
B
D
A
C
B
C
So
Mikey
asked
a
question,
maybe
connected
question.
Not
does
recording
the
file
system
assist,
calls
on
the
machine
enough
for
salsa
level
3
without
having
a
specific
Builder,
not
exactly
I
mean
we
can
there's.
Definitely
some
areas
where
doing
stuff
like
ebpf
and
so
on
could
help
out
like,
especially
if
we
end
up
going
like
a
salsa
level.
C
The
secure
salsa,
Builder,
API,
right
and
Jenkins
calls
the
secure,
salsa
Builder
API,
as
opposed
to
saying
Jenkins
itself.
Does
this
salsa
stuff
and
so
Jenkins
goes
and
says:
hey,
you
know
run
this.
You
know
run
the
build
against
this.
You
know,
let's
just
say
for,
for
example,
is
just
like
run
make
against
this
commit
right:
okay,
cool
this-
that
secure,
Builder
goes
and
records
that
pulls
down
the
code
pulls
down.
Dependencies
runs.
All
of
that.
You
know
it.
C
C
So
you
need
to
securely
monitor
what
happens
in
the
build.
The
problem
here
with
something
like
a
Jenkins
is:
how
do
you
do
that
when,
if
you're
not
locking
down
Jenkins
itself,
like
so
there's
so
there's
two
main
things,
one
is
the
only
thing
from
the
build
side
that
needs
to
be
secured,
and
once
again
this
is
still
the
responsibility
of
the
Jenkins
is.
Is
the
Builder
cannot
mess
with
sorry?
C
Whatever
is
the
build
that
you're
running
cannot
mess
with
other
builds,
either
in
time
or
space
so
like
it
cannot
mess
with
another
build,
that's
happening
at
the
same
time,
so
you
know
you
can't
have
two
builds,
let's
say
running
on
the
same
infrastructure
that
can
in
any
way
interact
and
then
at
the
same
time
you
know.
One
of
the
things
that's
happened
in
the
past
is,
if
you
don't
want
to
have
a
situation
where,
let's
say
I
have
a
bad
build
right.
C
C
E
Like
okay,
so
Gradle
has
this
thing
called
the
Gradle
build
cache
which
is
used
in
Enterprises,
primarily,
and
it's
this
cache.
That
is
this
distributed
cache
where
every
single
build
is
writing
and
reading
from
the
centralized
cache
for
compilation,
steps
stuff
like
that
so
like,
if
you've
compiled
a
project
previously
on
one
build,
then
the
compilers
need
to
run
again,
which
is
significant
for
performance
like
yes,
I
love,
performance,
Improvement
and
it
makes
local
development
significantly
faster,
but
you're
gonna
hate
cradle.
C
You
know
one
of
the
things
that
we
want
to
be
able
to
do
is
we
want
to
be
able
to
have
like
that
ability
to
to
say:
hey
here
is
a
build
cache
this
build
cash?
Can
you
know
still
you
can
still
use
that
bill
cash,
but
there's
gonna
be
rules
around
it
and
there's
gonna
be
ways
to
secure
it
and
I
know
that's
going
to
involve
probably
figuring
out
how
to
work
with
Gradle
to
to
implement
that.
C
A
A
C
Yeah,
so
you
might
be
able
to
do
that,
but
it
would
require
like
essentially
the
same
way
that
you're
doing
reusable
work
where
we're
using
reusable
workflows.
You
need
to
make
sure
that
the
pipeline
is
in
no
way
configurable
by
the
end
user.
At
that
point
right,
you
know
the
only
inputs
are
stuff
like
you
know
the
commit
hash.
A
C
C
But
to
Matthew
I
think
if
folks
are
interested
I
think
we
would
be
like
this.
This
group,
or
who,
who
an
interested
set
of
folks
might
be
very,
would
be
interested
in
in
seeing
what
sorts
of
General
things
even
to
hit.
Let's
say
a
salsa
level,
two
or
whatever
in
a
in
a
decent
way
might
be.
You
know
via
Jenkins,
might
be
something
that
we
could
look
at
sure.
D
Yeah
level
two
is,
is
kind
of
what
what
I'm,
targeting
with
with
this
one-
and
you
know
just
letting
you
know
all
the
stuff
we've
talked
about
right,
restricting,
plugins
and
and
everything
else
is-
is
on
the
table,
for
you
know
what
I'm,
what
I'm
thinking
we
need
to
do,
right
and
and
the
people
I've
talked
to
you
know
within
the
company
all
seem
to
kind
of
you
know,
shake
their
head
and
go
yeah.
Well,
that's
probably
what
you're
going
to
need
to
do
and
it's
you
know
it's.
D
It's
not
gonna,
be
you
know,
you're
not
going
to
be
popular
when
you're
telling
people
they
can
and
can't
do
things.
But
then
you
know
as
as
long
as
we
can
make
sure
people
understand
that
maybe
they
just
need
to
in
some
cases
split
their
controllers
to
you
know,
put
their
their
build
tasks
onto
one
and
you
know
their
their
tests
and
other
tasks
that
you
know
they
they
do
need
to
customize
and
and
maybe
controlling
some
more
exotic
ways
that
it's
like
okay,
fine,
you
know
go
ahead
and
do
that.
D
Towards
at
least
a
salsa
level,
two
but
yeah
I'm
still
trying
to
fully
understand
like
The,
Groovy
script,
sandbox
and
things
like
that,
and
so
as
teams
use
custom,
groovy
scripts
and
their
pipelines
and
things
like
that,
how
much
they
actually
have
access
to
the
controller.
You
have
to
be
able
to
customize
the
control
plane
via
that
method
and
so
on.
C
Yeah,
so
so
it's
so
on
that
end,
you
know
The
Groovy
sandbox
is
actually
pretty
good
at
at
blocking.
You
know
the
ability
for
for
jobs
to
be
able
to
access
stuff
on
the
controller
end,
the
problem
more
is
it
just
makes
it
very
difficult
for
something
like
salsa
to
then
know
exactly
what
it
needs
to
be
looking
at.
C
You
know
like
if
you
had
a
salsa
Plug-In
or
you
were
wrapping
it
up.
You
know
there's
a
lot
of
stuff
there
that
that
gets
super
complicated
and
there's
a
lot
of
areas
where
you
can.
You
know
it
would
be
very
easy
for
if
you
gave
folks
to
the
to
the
even
The
Groovy
sandbox,
that
they
wouldn't
be
able
to
mess
with
other
builds,
they
wouldn't
be
able
to
mess
with
the
controller,
but
they'd
be
able
to
falsify
the
results
of
their
own
build,
which
is
what
you
don't
want
right.
D
D
There's
research
in
that
space
happening
right,
so
Marcella,
I'm
blanking
on
her
last
name
right
now.
So
it's
it's
not
even
eight
o'clock
here,
so
I'm
I'm
not
fully
operational.
Yet
she,
you
know
she's
working
in
the
the
spec
side
of
salsa
quite
a
bit,
but
you
know
they
have
a
lot
of
you
know
prototypes
going
on
related
to
you
know.
How
can
you?
How
can
you
do
your
runners
in
an
enclave
or
you
know
TDX
VM,
so
that
you
can
use
it
to?
D
You
know
attest
that
you
know
you
have
a
certain
environment
and
it's
able
to
monitor
what's
happening
and
things
like
that
and
you're
able
to
attest
to
the
actual
Hardware
config
that
it
ran
out
right.
So
so
yeah
I
mean
there's
definitely
an
opportunity
to
leverage
that
in
the
future
right
because
gotta
deploy
that
Hardware
to
to
actually
run
that
in
the
build
environment-
and
you
know
you
know-
even
Intel-
has
restrictions
on
how
much
of
that
it
can.
D
E
C
Cool
cool,
yeah
and
I
know
that
you
know
doing
this
in
the
startup
life.
We
also
cannot
afford
that
Hardware,
at
least
yet
you
know
but
but
we're
very
interested
in
seeing
where
it
goes,
and
also
perhaps
renting
that
Hardware
from
a
cloud
provider
for
very
short
amounts
of
time
right,
yeah,
but
but
that's
cool,
yeah,
yeah,
so
I
know
you
know,
there's
some
stuff
right.
That's
discussed
around
there
as
as
well,
but
yeah.
This
is
super
useful
I
I
will
spend
some
time.
C
Just
kind
of
you
know,
prepping
a
document
so
that
I'll
share
inside
of
the
salsa
Dash
tooling
a
a
chat
in
a
little
bit
and
we
can
probably
just
start
throwing.
You
know
just
a
couple
of
thoughts
out
there.
Matthew
I
know
you
have
a
you've,
probably
been
working
with
Jenkins
more
than
the
rest
of
us.
Recently.
D
C
Yeah,
so
I
do
think
it's.
This
is
going
to
be
an
interesting
project,
probably
consisting
of
both
a
set
of
like
rules
around
like
the
way
I've
been
thinking
of
it
is
based
on.
What
you
had
said
is
like
hey
here
are
things
that
you
should
do
to
secure
and
lock
stuff
down,
and
then
here
are
also
perhaps
ways
to
sidestep
it
by
using
other.
C
D
D
C
Yeah
yeah,
so
I'll
set
that
up
I'll
send
it
out.
I
know
we
only
have
five
minutes
left,
but
does
anybody
else
have
any
other
things
they
wanted
to
to
bring
up
and
then
also,
if
folks
know,
people
who
use
Jenkins,
who
want
a
salsified
Jenkins
and
are
interested
in
actually
contributing
please
bring
them
along
I,
definitely
want
folks
on
this
side.
C
D
C
Cool
any
other
things
folks
wanted
to
bring
up
in
the
last
couple
of
minutes,
otherwise
see
all
next
week
and
I'll
also
be
reaching
out
to
some
folks
about
maybe
trying
to
promote
this.
This
meeting
a
bit
more
so
that
we
get
a
a
little
bit
more
engagement
and
a
little
bit
more
folks
who
are
interested
in
in
participating
in
tributing.