►
B
C
C
So
I
wanted
to
extend
an
offer
and
say
if
you
want
to
grab
space
on
the
agenda,
we
would
love
to
hear
about
you,
but
if
you're
just
here
to
observe
that's
totally
fine
as
well,
is
the
agenda
accessible
to
you
all
I
have
and
drop
it
in
the
chat.
It
should
be
on
the
calendar,
invite
on
the
open,
ssf,
Google
Calendar.
C
C
C
Start
and
again
we're
we're,
not
started
yet
we're
gonna
wait
a
little
bit
for
for
Farm,
but
we
can
start
with
introductions
as
a
teaser
and
then,
if
there's
times,
maybe
in
New
York
pitch
again,
the
project
generally
I
think
folks
would
be
interested
in
hearing
that
for
for
context.
If
this
is
your
first
meeting
I,
hopefully
some
of
this
is
is
evident
from
the
group
Charter.
C
But
this
is
the
open,
ssf
securing
software
repositories
group
it's
a
place
where
we
try
to
get
together
a
bunch
of
folks
who
are
involved
in
you
know
administering
running
writing
new
package
repositories,
maintaining
existing
ones
in
the
code
bases
for
those
and
are
interested
in
doing
so
in
a
secure
way.
So
we
cover
a
bunch
of
things.
We
cover
my
pet
favorite
topic
is
cryptographic
signing
of
packages,
but
that's
you
know
closely
related
to
package
provenance.
How
to
build
packages
correctly.
C
Can
we
do
reproducible
build
tricks
to
you
know
make
sure
that
the
packages
that
are
were
being
handed
we're
pretty
confident
we're
built
from
Source
all
all
that
sort
of
stuff.
We
typically
have
attendees
from
both
just
interested
parties
and
attendees
to
in
minister
of
packing
managers.
We
often
have
representation
from
pipe
Pi,
although
I
think
it's
maybe
a
little
too
early
for
him.
Ruby
Ruby,
Jones
npm,
occasionally
occasionally
the
cargo
folks,
slang
and
I've
seen
folks
from
Gen
2
PHP.
C
So
it's
it's
a
fun
crowd
a
lot.
It's
a
big
big
challenge
as
I'm
sure
you
know,
and
especially
retrofitting
a
lot
of
you
know
the
reproducible
build
folks,
in
particular
I'm
sure
know
about
the
challenges
of
retrofitting,
a
good
security
idea
on
disk
systems
that
were
utterly
unintended
for
them,
and
the
whaling
and
matching
the
two
that
accompanies
that.
So
we
here
we
hear
a
lot
about
that,
but,
like
other
things
that
are
in
scope
include
like
just.
C
Authentication
policies
for
taking
down
malware
policies-
for
you
know,
yanking
packages-
think
about
your
left
hand
incident
all
all
of
the
above
concerns
about
user
privacy.
Obviously
here
and
all
this
so
I
will
we're
almost
five
past
the
hour.
I
guess
it's
gonna
be
slightly
lightly
attended,
just
as
we're
really
early
into
the
new
year,
so
I'm
happy
to
get
us
get
this
going.
I'll
drop
the
agenda
once
more
into
the
chat.
C
All
right
and
then
feel
free
to
pop,
in
add
your
name
to
the
agenda
attendee
list.
If
you
would
like
nice
to
keep
track
of
who's
showing
up
and
then
yeah
again,
it's
still
open
ad
items
to
it.
So
I'll
start
with
the
introduction
item
on
the
agenda,
so
I
I
did
a
little
bit
of
this
in
the
moments
before
introducing
this
meeting,
but
welcome
everyone
to
the
first
2023
openness,
success,
security,
software
repositories.
Meeting
we
have
a
few
interesting
items
on
the
agenda.
C
D
B
D
I'll
say
hi
I
mean
and
also
to
also
essentially
also
introduce
Holger
and
Matia,
so
I'm
I'm
Chris,
oh
I,
can
recognize
more
people
here.
Oh
hey
Lucas
yeah,
so
we
are
all
from
reproducible
Worlds
and
we
saw
that
there
was
a
a
meeting
that
was
relevant
and
within
our
time
zone.
I
think
I'd
seen
it
before.
D
D
Doesn't
really
know,
reproducible
builds
started
in
its
modern
Incarnation
started
as
a
as
a
sort
of
very
mild
intro
as
an
interest
within
the
Debian
project.
So
I
mentioned
that,
particularly
because,
in
other
words,
a
lot
of
our
perspective
and
focus
has
been
on
distribution
concerns.
I
mean
as
in
in
terms
of
like
the
packages
within
a
distribution
and
the
source
and
binaries
of
distribution,
not
necessarily
what
is
now
considered
under
the
rubric
of
a.
B
D
D
A
C
C
So
I
will
take
a
moment
to
say
that
I
think
a
distribution
package
managers
are
definitely
in
scope
for
this
meeting.
I
think
our
Charter
makes
that
clear.
It's
sort
of
an
accident
of
History
that
we
haven't
had
more
representation
from
distro
folks,
but
would
love
to
see
more
of
them
and,
in
fact,
if
you
want
to
tell
your
friends,
I
think
I
think
you
know
Network
wise
the
language
ecosystem
package
repository
folks
just
know
each
other
more
more
closer
than
we
know
any
any
folks
from
the
distribution.
C
E
Well,
I
have
some
slides,
because
then
you
can
look
at
them
and
not
me
and
then
I
can
make
sure
I
don't
forget
anything,
so
we
so
Cairo
who's.
Here
is
all
on
the
call
presented
this
project
sometime
in
calendar
Q4
last
year,
but
we
have
this.
This
project
we've
been
working
on
a
VMware
called
rsstuff
repository
service
for
tough
and
effectively
we're
trying
to
make
it
easier
to
adopt
tough
and
integrate
it
into
kind
of
package
repositories.
Stuff.
E
This
python
enhancement
proposal
pep
458
for
a
very
long
time
about
integrating
tough
into
Pi
Pi
and
we've
had
William
Woodruff
at
trail
of
bits
did
a
like
a
preliminary
pull
request
to
integrate.
This
I
think
it
was
last
year-
and
this
was
this
ended
up
being
like
a
huge,
a
huge
and
relatively
deep,
like
change
to
the
pipeline
code
base
and
so
getting
folks
to
review
it
and
helping
those
folks
develop.
E
The
the
appropriate
level
of
context
was
was
something
of
a
challenge
then,
about
six
months
ago,
Cairo
joined,
VMware
and
and
started
looking
at
this
and
updating
the
patch
set.
That
William
had
originally
authored
to
work
on
changes
to
the
Upstream
python,
tough
Library,
and
while
he
was
doing
this
work
and
thinking
about
how
deep
of
a
change
this
was
and
how
like
how
complex
it
was
to
review
he.
He
started
this.
This
project
called
our
stuff,
which
is,
as
I
said
in
the
first
point.
E
The
goal
of
the
astral
project
is
to
implement
common
patterns
for
adopting
the
tough
framework.
So
today
we're
focused
on
this
pet
458
design.
That
I
already
mentioned,
there's
also
another
python
enhancement
proposal
pep480,
which
moves
to
adding
individual
developer
signing
and
the
plan
is
for
our
staff
to
grow
features
to
support
that
like
pattern
as
well,
but
and
who
knows
what
the
future
will
bring,
but
really
what
we
we
believe
as
we've
developed
this
project.
E
E
E
C
Awesome
thank
thanks.
Joshua
before
we
get
into
anything
like
decisions
or
are
people
in
favor
of
this
I
want
to
take
a
moment
to
just
ask
for
questions
is
the
context
player?
Is
there
anything
we
can
elaborate
on
and
is
I
think
the
ask
is
pretty
clear
so,
but
do
folks
kind
of
get
what
our
stuff
is,
what
it's
doing
why
it
could
be
of
interest
to
folks
in
this
group.
D
D
B
E
One
of
the
challenges
in
getting
it
approved
was
expertise
to
review
the
pep
it
talks
about.
It
assumes
a
certain
familiarity
were
tough.
It's
talking
about
software
supply
chain
security
attacks
which
until
a
couple
of
years
ago,
not
that
many
people
were
aware
of
or
interested
in,
and
the
bar
to
reviewing
the
pep
and
being
able
to
constructively
review
the
pep
was
quite
High.
E
So
we
did
a
bunch
of
work
to
lower
that
bar
in
collaboration
with
reviewers
in
the
the
python
community
and
then,
when
the
pet
was
approved,
we
set
to
working
on
it.
While
we
were
doing
that
work,
we
had
this
python
implementation
of
turf
that
had
been
developed
alongside
the
spec,
and
there
were
some.
E
There
was
some
performance
and
API
interaction
trapped
in
that
code
base
that
we
discovered,
while
we
were
trying
to
implement
this
integration.
So
a
few
folks
went
off
and
rewrote
this
library
from
scratch,
got
it
security
audited,
and
then
we
came
back
to
finish
integration
work
and
it's
at
that
point
that
the
story
I
told
today
started
where
Cairo
came
along,
started
doing
that
integration,
work
and
realized
that
you
know
Pipi
is
a
reasonably
large
code
base.
It's
a
reasonably
complex
service.
E
C
Yeah
I
just
want
to
add
two
quick,
quick
notes
of
color.
If
I
recall
correctly,
there
actually
is
a
PR
that
someone
wrote
against
a
warehouse
which
is
the
implementation
of
IPI
yeah
and
the
Pi
Pi
team
was
uncomfortable
reviewing
it
due
to,
as
you
mentioned,
the
invasive
nature
of
the
change,
so
not
just
the
theoretical
concern,
but
someone
had
actually,
you
know
tried
this
out,
and
you
know
it's
been
lingering,
because
no
one
feels
comfortable
saying.
C
Yes,
this
looks
secure
to
me
and
it's
tightly
coupled
to
a
lot
of
the
rest
of
Warehouse,
which
leads
me
I.
Guess
to
my
my
second
point,
which
is
this
just
that
architecturally,
it's
quite
nice
to
be
able
to
have
a
confined
interface
for
your
the
security
part
of
the
system.
So
we
can
do
a
Security
review
of
a
self-contained
box
and
then
say
as
long
as
you're
using
it
for
these
instructions.
F
Yes,
I
have
a
quick
one.
One
piece
of
feedback
I
would
have.
Is
that
as
another
small
team
trying
to
maintain
a
Production
Service,
we
are
unlikely
to
take
a
whole
dependency,
Lock,
Stock
and
Barrel,
if
it
that
implements
core
logic
that
we
care
about
it's
possible,
but
not
a
good
assumption,
so
the
documentation
about
why
you
made
these
decisions
where
you
ended
up,
why
other
people
have
had
difficulty
in
the
past
is
much
more
valuable
to
me
than
the
code
base
I'm
likely
to
choose
to
re-implement.
F
Consolidated
implementation
I
think
this
is
a
great
project.
I
know
that
I
have
looked
at
tough
for
three
to
five
years
now,
and
it's
made
no
sense
to
me
and
then
I
after
having
tried
that
I
went
back
and
reread
a
PR
someone
made
to
add
tough
to
the
ecosystem,
I
work
on,
and
you
know
the
tenth
time.
I
read
it.
It's
like.
Oh,
this
actually
makes
sense.
C
Awesome
then
I
will
yeah.
I
will
Echo
what
everyone
says
that
that
in
general
it's
It's
tricky
to
get
grasp
on
tough.
This
is
certainly
something
I
know.
I've
seen
a
few
faces
on
the
call
who
are
sort
of
core
to
that
team,
and
this
is
something
that
they're
aware
of
and
struggling
with.
You
know
it's
hard
to
know.
I.
Think
a
bunch
of
this
complexity
is
inherent
to
the
problem
domain.
C
There's
a
number
of
like
quite
subtle
attacks
that
that
tough
is
trying
to
deal
with,
but
hopefully,
hopefully
over
time.
We
kind
of
improve
the
tooling
and
improve
the
the
ability
to
adopt
so
I
guess
with
that
said,
as
a
as
a
I
guess
front
point
of
process,
the
charter
of
this
group
gives
us
quite
limited
decision-making
power.
G
C
C
B
G
G
E
Mostly
that,
like
I
I,
recognize
the
maintenance
person
we're
not
asking
to
donate
this
project
and
walk
away.
We're
asking
to
continue
to
work
on
it
just
within
a
different
organization
that
better
conveys
the
neutral
like
yeah
the
neutrality
of
the
project
and
hopefully
makes
it
easier
for
potential
users
to
find.
G
E
E
G
G
H
Yeah
I
got
a
call,
I'll
come
back
in
a
second
I
I
can
give
you
some
insight
how
we
did
it
on
SKF,
but
yeah.
You
need
to
have
a
working
group
sponsor
it,
and
then
you
present
it
to
the
attack
as
like
something
you
want
to
do.
But
I
will
say
that
the
attack
is
kind
of
backed
up
right
now,
so
you
might
not
really
get
an
answer
back
till
March,
maybe
so
yeah
just
for
the
record.
C
C
H
C
I
G
B
B
G
H
Yeah,
but
having
some
goal,
having
some
goals
in
mind
is
not
bad,
because
I
know
that
that's
something
they've
asked
for
us
at
SKF,
which
is
substantially
larger
project,
but
having
maybe
like
this
is
what
we,
how
we
plan
or
what
we
intend
to
do.
This
might
be
a
way
of
tracking
it
and,
as
Josh
said,
reporting
on
that
periodically
might
be
also
good,
because
that's
one
of
the
things
that
has
come
up
is
how
do
you?
H
How
do
you
gauge
success
in
your
project
and
also
going
on
with
what
Zach
said
yeah
like
you,
could
even
Fork
projects
out
of
Linux
Foundation?
Should
that
be
a
issue
which
is
kind
of
our
risk,
which
is
what
they
told
us,
so
the
project
being
an
open
ssf?
Does
it
encapsulate
it
in
any
way,
shape
or
form.
H
A
person
you
can
talk
to
is
Chrome
is
very
good
at
guiding
people
through
this.
He
guided
us
so
he's
a
great
resource
and
very
helpful.
So
if
you
want
me
to
want
to
hit
him
up
on
Slack
and
asking
that
you
want
to
present
something
to
the
tech,
he
can
give
you
more
my
new
details
on
what
you
need.
You
might
want
to
grab
that
presentation
from
Jacob,
because
you
might
need
that.
So
the
same
excellent.
C
All
right,
excellent,
yeah,
so
I
see
in
the
chat
there's
a
good
question
that
I
think
is
we'll
do
at
the
end.
If
we
have
time
about
the
relationship
between
tough
and
in
total
I
think
it
actually
is
particularly
of
interest.
If
you
are,
a
reproducible,
builds
type
of
person,
and
so
so
we
can
kind
of
get
into
that.
But
first,
let's
move
on
with
the
rest
of
the
agenda.
Joshua
again
tell
us
about
salsa
1.0.
E
E
It's
a
cross-industry
collaboration
based
on
work
originally
done
at
Google,
and
it's
kind
of
targeting
build
system
and
package
ecosystem
developers,
which
is
you
know,
wave
Emoji.
Why
I'm
here
hello,
we've
had
a
salsa
0.1
version
published
on
salsa.dev
for
quite
a
long
time
now,
and
we're
really
pushing
for
a
a
draft
of
the
next
release,
which
is
going
to
be
our
1.0
kind
of
stable
release
and
we're
aiming
to
get
that
into
draft
and
push
it
through
an
active
review
period
by
the
end
of
this
month.
E
That's
one
of
the
reasons
I'm
here
and
I
thought.
I
could
just
kind
of
give
a
brief
overview
of
the
things
that
are
changing
just
in
case
folks
are
familiar
with
salsa
in
his
current
incarnation,
but
maybe
before
I
do
that
I
should
ask
if
folks
are
like
if
the
audience
is
predominantly
not
familiar
with
it.
Maybe
this
is
the
wrong
position
to
you
know
the
wrong
side
to
speak
to
for
five
minutes.
So
are
folks
generally
familiar
with
that
in
this
group.
E
E
E
Okay,
I've
gone
old
old
thing.
We
can
look
at
okay,
so
this
is
like
a
diagram
of
a
have
a
fairly
typical
software
supply
chain
and
developers
submit
some
source
code
to
revision,
control
repository
some
build
system
kind
of
pulls
in
a
bunch
of
dependencies
and
builds
that
source
code
into
some
kind
of
package.
It
gets
distributed
to
and
some
kind
of
end
user,
and
so,
as
these
red
arrows
indicate,
there's
lots
of
places
where
things
can
go
wrong
in
this.
A
E
The
the
target
audience
is
people
who
develop
systems
which
Orchestra
and
build
software
so
like,
for
example,
you
know
techtrons
or
internal
platform
teams
or
GitHub
actions,
kind
of
systems
that
kind
of
yeah.
That's
that
that
kind
of
I
don't
have
a
good
time
to
use
instead
I'm
afraid.
But
that's
what
we
generally
mean
when
we
refer
to
build
system
in
the
salsa
project.
E
B
C
C
Okay
and
then
we
can,
we
can
come
back
to
anyways
in
time
at
the
end,
follow-up
from
all
right,
I
put
I
volunteered
Brandon,
but
I,
don't
think
he's
on
the
call.
A
while
ago
there
was
a
survey
that
went
out
to
folks
running
again,
mostly
language
ecosystem
package
managers
on
a
large
number
of
things,
so
that
includes
multi-factor
authentication.
That
includes
cryptographic
signing
packages
that
includes
all
all
manner
of
security
measures,
and
so
that's
gone
out.
C
We
have
responses
the
responses
containing
possibly
some
information.
We
don't
necessarily
want
to
publish,
namely
it's
a
list
of
various
weak
points
on
various
repositories
which
we
will
hopefully
in
time
address,
but
don't
want
to
hand
to
someone
who's
looking
for
opportunities
at
the
moment,
so
we're
going
to
keep
the
data
under
light,
locking
key,
if
you
can
explain
yourself
as
someone
with
a
connection
to
the
ecosystem,
I
think
they
will
give
you
access,
but
but
we're
not
publishing
it.
C
So
the
follow-up
there
is
to
sort
of
say
hey.
Can
we
turn
that
into
a
public-facing
report?
Identify
some
Trends
identify
areas
for
investment
again,
not
in
a
way
that's
going
to
put
a
Target
on
anyone's
back,
so
the
response
I
got
from
Brandon
recently
was
basically
we're
pretty
close
to
that
point.
There
are
a
couple
ecosystems
that
wanted
to
amend
some
of
that
out
of
eight
given
us,
so
we're
waiting
on
that
before
we
roll
out
a
public
report,
but
that
public
report
is
in
progress.
F
C
What
slackers,
okay
I'll
do
that
thank
you
yeah
and
and
then
and
then
feel
free
to
bring
it
up.
If
you
haven't
gotten
a
response
by
the
next
meeting,
but
I
think
I
think
that's
probably
what
what
happened
there.
Cool
next
next
item
on
the
agenda
is
another
follow-up.
This
one
is
me
and
I
will
say:
I
totally
dropped
the
ball
on
it
again
for
related
reasons
to
what
we
were
just
talking
about
not
really
being
at
work.
C
We've
noted
that
there's
a
number
of
groups
in
the
open
ssf,
along
with
folks
outside
especially
academic
researchers,
who
have
been
interested
in
data
around
you,
know
how
many
packages
are
getting
yanked
and
why
and
actually,
if
I
can
ask
if
someone
knows
the
tweet
that
Dustin
dropped
a
little
while
ago
on
some
of
the
take
down
data
for
Pi,
Pi
and
dropping
that
in
the
chat
or
the
node
stock
would
be
awesome,
because
that
was
pretty
interesting.
But
this
is
stuff.
C
That's
not
widely
available
that
we
kind
of
have
to
lean
on
package
repository
administrators
for
at
the
moment,
and
so
it
would
be
really
cool
and
useful
as
a
community
of
people
seeking
to
understand
risks
here.
Much
like
we're
collecting
data
qualitatively
on
the
package
repository
ecosystem
with
that
survey
and
then
quantitative
data
would
be
extremely
useful
as
well.
So
I
was
supposed
to
and
did
not
and
I
will
hopefully
address
that
post-taste
prepare
basically.
C
Of
what's
what's
that
going
to
look
like
you
know
what
data
are
we
interested
in?
So
we've
talked
about
things
like
domain
squatting,
risk
information
right,
there's
there's
this
worry
about
I
sign
up
for
an
account
with
the
email
address
at
a
custom
domain
and
then
I.
Let
that
domain
lapse.
Someone
else
realizes
that
they
they
can
register
that
domain
and
start
getting
my
email
and
then
they
can
log
in
and
publish
a
package.
As
me
like.
C
There
were
things
about
again
takedown
rates.
What
fraction
of
packages
are
malicious?
Are
we
taking
down
mostly
spam
packages?
Are
we
taking
anonymously
malware
information
about
downloads
information
about
typo,
squatting
in
names
of
packages?
All
that
could
be
useful.
We
see
a
lot
of
academic
research
where
it's
so
much
work
to
collect
this
information
from
one
package
ecosystem
that
they
say.
C
Okay,
we're
gonna,
do
a
deep
dive
on
you
know,
type
EI
or
npm
for
this
paper
and
those
cross
ecosystem
comparisons
would
be
extremely
valuable
and
so
I
think
facilitating
that
by
kind
of
collecting
this
data
and
standard
formats
would
be
super
balance.
So
I
have
to
write
down
what
I
just
ranted
at
you
about
in
a
document
and
then
come
back.
C
H
Something
that
I've
been
bringing
up
because
I'm
an
old
Linux,
Community
member
involved
with
the
distros
and
like
Homebrew,
and
things
like
that
lately,
there's
been
a
big
misconception
like
I,
think
that
if
we
being
the
securing
software,
repos
group
put
a
guide
because
basically,
what
it's
been
brought
to
my
attention
is
that
what
we
do
in
the
Linux
Community
is
more
like
an
end
user
thing.
So
it
the
end.
H
Goals
are
different
from
say:
Pi,
Pi
or
ruby,
gems,
or
anybody
like
that,
and
there
is
talk
from
some
very
important
Linux
members
about
how
Linux
Foundation
openssf
is
completely
tone,
deaf
to
what
really
happens
and
I.
Don't
necessarily
agree
with
that
standpoint.
I.
Just
think
that
we
attack
different
things
and
unfortunately,
two
things
share
a
name
and
I
think
maybe
that
should
be
rectified,
because
now
there's
also
a
new
group
pushing
the
next-gen
packaging
formats,
which
is
flat
pack
and
snap,
and
that's
just
going
to
add
more
confusion
to
the
whole
thing.
C
H
There's
some
conflation
there,
or
is
it
correctly
correct,
like?
Let
me
give
you
a
very
good
example
like
Homebrew
Homebrew,
most
Homebrew
users
expect
Homebrew
to
be
safe.
In
other
words,
they
expect
us
to
only
distribute
like
safe
packages,
and
that's
the
thing
it's
not
about
salsa,
it's
not
about
guac,
it's
not
about
Fresca.
They
really
don't
care
about
any
of
that.
They
don't
care
about
s-bombs.
H
They
really
just
care
about.
Like
hey
I
installed
it
you
had
it
I
installed
it
it's
here.
If
it
wasn't
secure,
then
why
are
you
carrying
unsecure
software?
You
needy,
which,
like
you
know
so
there's
there's
definitely
like
I,
would
argue
a
a
difference
there
of
opinion
and
I
think
approach
that
needs
to
happen
because
at
Gen
2
it's
the
same
thing,
I've
heard
from
the
Debian
maintainers.
It's
the
same
thing
and
that's
why
they
change
packages
around
and
it.
But
it's
just
a
different
point
of
view.
H
G
I
I
agree:
I
guess
I
would
have
two
notes,
though,
like
two
but
two
butts
the
first
one
would
be
if
we're
turned
off
it's
not
because
we're
turned
off
it's
more
that
we
just
haven't
heard
from
folks.
So
it's
really
good
that
you're
here
Randall
to
help
us
see
that
and
the
other
one
would
be
like
a
matter
of
scale.
I
got
into
a
what's
the
technical
term,
a
pissing
match
with
due
default.
G
H
G
And
that's
that's
the
difficulty
right
of
like
a
created
approach
is
that
it
it
someone
limits
and
there's
also
the
advantage
that
a
lot
of
cases,
various
distributions
can
sort
of
kind
of
cause
I
rely
on
each
other
to
keep
an
eye
on
them.
The
hen
house,
so
there's
there's
some
shared
load
there,
but
that's
just
not
true
of
the
package
ecosystems
like
every
package,
like
what
works
for
Pi
Pi.
What
PPI
monitors
does
not
help
ruby
gems
and
vice
versa.
H
And
another
thing
that
came
up
another
thing
that
came
up
in
the
shirt
that's
interesting
job
is
that
I
have
been
told
by
several
software
developers
like
big,
like
the
curl
people.
That
would
be
really
helpful
if
distro
stopped
trying
to
fix
things
on
their
own
in
their
own
isolated
environment,
and
then
they
end
up
with
60
patches
that
no
one
knows
where
they
came
from
so.
D
H
G
H
I
agree:
I
could
definitely
bring
those
people
around
for
you
guys.
Some
some
of
them
are
a
little
bit
more
difficult
than
others,
but
you
know
I'm
sure
I
could
bring
with
time
a
lot
of
people
around,
but
I
just
think
it
would
be
good
to
have
guidance.
So
therefore,
there
isn't
because
sometimes
there's
this
thing
like
we
got
or
we
as
when
I
say
we
guys
isn't
open.
Ssf
is
championing
salsa
and
Fresca
and
guac,
and
that's
just
not
something
we
could
really
do
from
like
an
end
user
packaging
perspective.
B
C
F
No
I
just
put
it
up
sorry
about
that.
The
topic
of
this
item
is
Greenfield
opportunities
and
so
for
context.
I'm
one
of
the
cargo
contributors
who
received
the
drive-by
contribution
of
just
you
salsa,
which
has
been
sparked
a
really
interesting
conversation
and
I'm.
Perhaps
you
know
I'm
here
I'm,
perhaps
one
of
the
most
receptive
audiences
you
could
get,
and
even
so
there
is
something
different
about
it
in
Greenfield
than
there
is
in
other
ecosystems.
F
In
that
all
the
explanations
they
went
to
were
about
how
salsa
is
better
than
your
current
signing
solution,
we
don't
have
a
signing
solution,
so
the
argument
needs
to
be
Rewritten
as
here's.
Why
it's
better
than
doing
nothing,
which
is
in
some
ways
much
easier
and
in
some
ways
much
harder,
but
it's
definitely
a
different
argument,
so
the
bigger
feedback
to
expand.
That
is,
if
you're
coming
to
a
green
field
or,
if
you're,
an
expert
trying
to
save
someone
who
came
to
a
green
field.
C
C
F
I
guess
I
didn't
make
myself
clear,
because
I
think
I'm
largely
agreeing
with
you
also.
The
group
cannot
stop
those
drive-by
contributors.
What
we
can
do
is
seeing
that
they're
happening
write,
good
documentation
that
is
aimed
at
Greenfield
projects
at
people
who
are
just
jumping
in
at
people
who
don't
necessarily
have
the
baggage
that
Tulsa
was
intended
to
fix
and
and
then
when
those
drive-by
contributors
make
their
contribution,
they
can
point
to
our
documents
and
say
Here's
why
you
should
do
it
as
a
Greenfield
project.
C
Excellent
yeah,
okay,
then
yeah
sounds
like
we're
totally
on
the
same
page
and
I
will
also
just
commend
you
by
proxy.
The
conversation
in
the
rust
Community
has
been
consistently
extremely
good
and
nuanced.
On
this
point-
and
you
know
this
is
a
strength
and
also
argue
about
a
weakness
of
the
rest.
Community
is
you
guys
in
in
gals,
want
to
want
to
get
things
right
and
so
and
so
I've
really
enjoyed
a
lot
of
that
conversation.
C
I
think
there
are
people
thinking
really
hard
about
all
these
problems,
and
so
we
will
we
will
likely
trip
it.
So,
given
that
we
only
have
a
couple
minutes,
left
I,
don't
know
if
we
want
to
conclude
anything
here.
If
someone
were
to
vote,
if
I
had
more
hours
in
a
day,
I
would
volunteer
to
try
to
coordinate
writing
some
guide
and
some
you
know,
materials
for
the
setting
in
lieu
of
that.
D
C
That's
a
great
idea:
it's
yeah!
This
is
a
60
page.
Note
stack
at
this
point,
so
we
probably
should
have
a
better
system
for
that.
I
can
I
can
take
that
as
an
action
item,
a
sort
of
like
solicit
some
discussion
in
the
slack
about
what
do
we
do
with
ideas
that
we
want
to
do,
but
aren't
going
to
get
so
I
can
give
that
to
myself
and
then,
as
a
follow-up
from
that
track
tracking.
This
would
be.
E
C
Oh,
that
is
a
great
Point.
All
right,
I
will
yeah
I
I
just
haven't
looked
at
that
issue,
tracker
ever
so.
Well,
all
right.
Two
minutes
left
I,
have
there's
a
great
question
earlier
that
I
want
to
address,
because
I
think
I
can
do
it
without
causing
more
confusion.
In
two
minutes,
though,
don't
hold
me
to
that
the
relationship
between
tough
and
in
Toto
so
dramatically
oversimplifying
I.
Think
of
tough
as
a
system
for
I'm
a
package
Repository.
C
This
is
how
we
we
decide
who's
in
charge
of
any
individual
package.
So
I
would
say
something
like
Joshua
is
the
person
I
trust
for
the
salsa
package
and
then
you
would
be
able
to,
and
that
would
maybe
embed
you
know,
public
key
information,
then
you
as
a
client
would
be
able
to
download
the
package,
see
a
signature
on
that
package.
From
that
key
zooming
out,
you
can
think
of
Joshua.
Is
the
person
who's
allowed
to
sign
this
package
as
just
a
policy
for
determining
whether
a
package
is
good
or
not?
C
You
might
be
interested
in
much
more
complex
policies
like
maybe
your
package
is
good
only
if
Joshua
signed
the
source
and
then
some
trusted
cicd
system
built
the
source
or
in
the
case
of
reproducible
builds.
You
know
multiple
CI
CD
systems
built
it
and
got
the
exact
same
output
and
specifying
a
policy
like
that
is
the
domain
of
in
Toto
and
so
an
ideal
system
for
doing
this
would
have
something
like
tough,
basically
delegating
to
for
each
individual
package
and
in
total
layout,
which
specifies
the
policy.
C
So
you
would
hang
the
top.
The
in
total
policies
off
of
tough
and
tough
would
be
the
mechanism
by
which
you
securely
distribute
them,
and
then
there's
also
other
important
roles
that
tough
plays
in
distributing
the
the
out
of
state
or
like,
like
tracking
the
material.
That
proves
that
a
policy
is
complied
with.
C
So
hopefully,
that
didn't
raise
more
questions
than
it
answered,
but
that's
that's
roughly
how
we
think
about
it.
So
thanks
for
indulging
me
and
if
you
wanna
hop
in
the
slack,
would
be
happy
to
have
that
discussion
in
more
detail
and
omit
fewer
of
the
details
that
I
omitted
to
make
it
technically
somewhat
wrong
all
right!