►
Description
Meeting minutes: https://docs.google.com/document/d/1-f6m442MHg9hktrbcp-4sM9GbZC3HLTpZPpxMXjMCp4/edit#heading=h.pujncb7gxv4f
A
A
C
A
A
C
C
All
right,
let's
get
the
show
on
the
road.
Let
me
just
post
the
link
to
the
notes
in
the
comments
section
or
the
chat
section
so
folks
can
hop
in
if
you
haven't
added
your
name,
please
do
so
that
helps
us
know
who
attended
and
so
that
we
know
who's
coming
and
we
can
talk
to
them
again
in
the
future.
The
first
thing
we
do
in
these
sessions
usually
is
introductions
and
new
faces.
B
D
B
B
Pretty
much
just
sort
of
reaching
out
to
this
group
to
see
if
there's
interest
in
participating
in
or
being
involved
in
sort
of
generalizing
or
creating
a
specification
for
how
package
metadata,
like
salsa,
attestations,
s-bonds
Etc
how
they
are
distributed.
You
know
and
found
for
for
folks
who
are
you
know
looking
at
software
repos
and,
and
you
know
whether
it's
GitHub
release
or
or
something
from
npm
or
Pi
Pi
so
on,
and
so
let
me
just
kind
of
go
through.
You
know
the
problem
today.
Right
is
we.
B
These
other
metadata
documents
might
need
to
support
multiple
different
ecosystems
when,
in
some
cases
we
might
be
able
to
have
something
similar
to
like,
let's
say,
oci
or
you
know
even
take
some
of
what
oci
has
done
in
similar
sorts
of
specifications
and
just
sort
of
say
hey
as
long
as
you
support
this,
you
know
we
can.
You
could
be
as
long
as
you
support
this.
B
You
can
easily
ingest
metadata
documents
coming
from
anything
that
supports
that
API
right
and
then
also
in
addition
to
that,
some
you
know
various
other
ecosystems
I
believe
Brew
was
one
of
them.
Homebrew
has
expressed
a
sort
of
desire
to
say,
hey.
We
we
don't
want
to
be
involved
in
generating
the
specification
or
generating
our
own
API.
B
For
this
we
would
much
rather,
if
somebody
else
sort
of
said,
here's
what
you
do,
you
just
need
to
either
implement
it
or
you
could
just
use
these
libraries
and,
and
then
this
like
API
thing,
and
you
know
you
just
sort
of
get
that
cool.
So
that's
that's
the
general
problem
here
and
then
to
kind
of
give
a
little
bit
more
of
a
background
on
some
of
this
right.
B
So
salsa
and
I
know
salsa
had
given
a
a
little
bit
of
a
presentation
either
last
week
or
the
week
before
so
salsa
is
a
security
framework
for
securing
artifacts
from
supply
chain
attacks.
It
does
this,
through
a
set
of
requirements
mostly
focused
on
the
build
right
now,
I'm,
mostly
focused
on
providing
provenance
of
artifacts,
so
that
you
know
that
this
code
led
to
this
output,
and
so
it's
two
things.
It's
that
set
of
requirements
as
well
as
a
a
metadata
document.
B
Format
referred
to
as
the
Providence
encodo
predicate
and
for
folks
who
aren't
super
familiar
with
Toto
in
totals
a
bunch
of
different
things
in
this
context,
in
Toto
is
a
another
metadata
format
where
somebody
can
say
this
is
a
signed
document.
So
it's
somebody
making
a
claim
about
a
thing
and
the
types
of
those
claims
are
referred
to
as
predicates
in
this
this
format.
B
B
So
if
I
have
you
know,
two
s-bombs
from
different
places
and
and
I
have
a
salt
satis
station
that
can
all
live
in
the
Manifest
and
you
know
what
it
points
to
in
there
and
then
the
other
thing,
that's
kind
of
pretty
common
about
all
of
these
documents
that
we're
talking
about
like
your
s-poms,
your
soul,
satisfations
and
so
on
is
they
are
us.
The
documents
are
associated
with
an
artifact
or
package,
usually
by
the
hash,
so
usually
by
the
checksum
of
that
package.
B
This
is
especially
true
with
s-bombs
it
sometimes
in
the
cases
where
either
the
checksum
isn't
known
or
in
certain
cases
where
the
checksum
doesn't
necessarily
really
indicate
what
it
actually
is,
because
it's
a
set
of
different
things,
all
structured
in
a
certain
way.
Sometimes
folks
use
package,
URLs
or
other
things
that
at
least
they're
trying
to
be
unique
identifiers
of
packages,
and
so
that
that
that
means
that
you
know
you
can
easily
the
the
goal.
Here.
B
So
just
so
you
have
an
idea
of
what
generally
we're
trying
to
do
here
is
if
I
go
over
to
whoops
something
like
this,
you
can
see
you
know.
There's
some
extra
stuff
doesn't
really
matter
right
now,
but
the
main
thing
is,
you
have
the
subject
which
this
is
sort
of
the
output
that
we're
referring
to.
So
this
could
be
a
python
package.
This
could
be
an
npm
package.
This
could
be
I,
don't
know
you
know
what
just
a
tarble
or
whatever-
and
there
is
you
know,
a
half
hash
associated
with
that.
B
So
you
can
imagine
in
in
many
cases
like
this
is,
let's
say
the
digest
of
an
image
or
something
like
that,
and
so
this,
and
so
when
folks
are
looking
for
that
they
sort
of
download
this
document.
It's
usually
signed,
they
can
verify
that
signature
and
then
they
can
look
at
all
the
stuff.
That's
in
here,
that's
you
know,
provide
some
additional
metadata,
mostly
related
to
the
build
for
for
salsa,
but
you
can
imagine
this.
B
B
We
want
to
be
able
to
have
some
metadata
that
can
only
be
associated
with
like
the
maintainer
of
the
package,
the
creator
of
the
package
and
for
certain
folks
they
want
to
know
like
hey.
Does
this
thing
use?
You
know
a
compromised
version
of
log4j
I
want
to
have
the
s-bomb,
but
how
do
I
know
if
that
package
even
has
an
s-bomb,
and
so
that's
kind
of
where
a
lot
of
this
desire
comes
in
is
how
do
we
both
distribute
it
for
ecosystems
and
so
on,
like
whether
it's
hey,
I'm
downloading?
A
B
Go
back
here,
and
so
you
know
the
ask
here
is
just
to
kind
of
actually
tie
it
back
a
little
bit
more
to
the
goals
again
end
users,
for
two
reasons:
you
know
end
users
from
the
perspective
of
somebody
who's
actually
using
the
actually.
Let
me
take
a
step
back
so
so.
There's
there's
two
main
users
of
what
we're
trying
to
what
we're
looking
at
here
is.
There
are
folks
who
are
building
tools
right,
so
this
could
be
the
PIP
Developers
for
python.
B
B
Are
there
s-bombs
associated
with
this
package
and
where
do
I
go,
find
them
right,
and
so,
for
example,
npm
is
looking
at
developing
they've
been
developing
an
API
that
allows
let's
say
end
users
to
be
able
to,
while
downloading
a
package
download,
Associated,
s-bombs
and
salsa
attestations.
So
it
was
still
when
you
know
a
developer
publishes
a
package,
they
would
also
publish
you
know
anything
like
an
s-bomb
signed.
B
Salsa
attestations
and
so
on,
and
then
for
the
end
user
who's,
then
downloading
it
can
download
it
either
when
they
actually
go
to
install
the
app
or
in
many
cases
for
folks
who
are
like
hey
I,
don't
want
to
install
it
if
it
doesn't
have
a
salsa
attestation
that
meets
my
requirements
check.
Does
this
package
have
a
salsa
at
a
station
before
I
download
it
and
then
download
the
salsa
attestation
first
run.
B
You
know
some
logic
policy,
whatever
it
matches
cool,
let
me
download
that
so
anyway,
the
the
ask
here
is,
you
know,
wanted
to
gauge
interest
with
this
group
and
also
going
to
probably
be
reaching
out
to
a
few
other
groups
within
the
open,
ssf
and
just
generally
in
the
open
source
Community,
but
wanted
to
see.
You
know
if
there
was
any
interest
on
defining
a
simple
specification:
I,
don't
think
we
want
to
kind
of
have
12
million
different
features.
B
Probably
some
simple:
if
I
give
you
a
unique
identifier
that
that
refers
to
a
package,
something
like
a
hash,
can
you
give
me
s-bombs
and
whatever
metadata
is
associated
with
it
and
then,
in
addition
to
that,
maybe
some
basic
search
functionality.
So,
if
somebody
said
hey,
I
want
to
find
all
s-bombs
associated
with
all
versions
of
this
package,
because
I
want
to
be
able
to
see
the
differences
between
them.
B
While
that
sort
of
specification
is
being
built,
I
think
some
folks
have
been
talking
about.
Are
there
things
we
can
do
in
the
the
meantime,
while
that
sort
of
specification
in
any
actual
implementations
are
being
out
being
built
out,
are
there
things
we
can
do
to
make
that
distribution
a
little
simpler
to
help
Drive
adoption
until
sort
of
something
that's
a
bit
more
rigorous
is
is
built
there
all
right,
that's
that's!
My
Spiel
is.
C
I
I
can
only
speak
with
the
ruby
gems
hat
on.
Unfortunately,
today
we
didn't
have
a
great
deal
of
turnout
for
your
presentation,
which
I
hope
you
won't
take
personally
I
just
think
it's
it's
a
complain.
It's
aligned
with
us
I
guess.
My
question
is
The
Proposal
here
for
document
format,
standards
or
is
it
for
an
API
like
what?
What
are
you
emphasizing
here?
I
wanted
to
understand.
B
So
the
the
thing
I'm
emphasizing
here
is
more
from,
like
you
can
imagine
something
like
I
want
a
rest,
API
spec
right
that
somebody
can,
let's
say,
hit
this
end
point
and
so
on
and
so
forth,
and
so
that
folks,
who
are
let's
say,
building
like
a
gem
like
an
update
to
gems
and
somebody
can
then
say
in
the
future.
You
know
Jim
might
have
a
flag
that
says
You
Know,
download
the
s-bomb
first
or
run
it
through
some
policy
or
whatever,
before
I
actually
download
the
rest.
B
And
so
this
is
the
same
thing
goes
with
like
pip
and
npm.
There's
some
stuff
here
about
about
like
hey.
If
if
this
does
not
have
a
salsa
attestation,
I,
don't
actually
I
want
to
error
out
right,
I,
don't
want
to
be
able
to
download
this
package
right
and
I.
Think
the
thing
that
folks
are
starting
to
ask
for
is
right.
So
there's
a
lot
of
people
are
starting
to
distribute
these
metadata
document
types
in
lots
of
different
ways:
different
package
ecosystems.
You
know
some
folks
are
just
sort
of
saying:
hey.
B
We
just
have
a
bunch
of
hatches
and
you
just
kind
of
look
up
the
hash,
dot,
Json
L
for
Json
lines
or
whatever,
or
you
know,
something.spdx,
and
that
that's
how
we
look
up
s-bombs
or
whatever
some
folks
are
looking
at.
You
know.
Oh
you
have
to
you
know,
there's
some
complicated
API
that
that
you
hit
some
folks
are
actually
saying
well,
no,
no.
B
We
just
package
up
any
s-bombs
and
Associated
metadata
in,
like
let's
say
the
tarball
or
whatever,
that
we
distribute
out
to
to
end
users
and
obviously
all
these
things
have
different
pros
and
cons,
but
I
think
one
of
the
biggest
issues
is
is
folks
have
started
to
express
like
hey
if
I'm
somebody
who's,
let's
say,
building
a
tool
to
help
out
here
right.
You
know
whether
it
is
the
PIP
or
whether
it's
some
separate
tool
to
say:
hey
I
want
to
do
some
security
analysis
or
whatever.
B
C
I
can
I
can
give
some
more
color
on
the
jam
side.
One
of
the
principles
of
Ruby
jams
is
that
they
do
not
edit
the
gem
file.
That's
received,
it's
it's,
you
know
identical
from
the
upload,
so,
for
example,
you
couldn't
crack
it
open
and
inject
an
s-bomb
or
injector
station,
or
anything
like
that.
They'd
have
to
be
side
by
side,
and
the
other
thing
I
would
note
is
that
whatever
design
came
about
would
have
to
be
as
CDN
friendly
as
possible.
C
Yes,
simply
because,
like
rubygems.org,
the
application
server
does
a
few
thousand
requests
per
second,
a
peak
I
think
but
like
the
CDN
in
front
of
it,
fastly
is
doing
like
millions
and
millions
per
minute
and
and
Ruby
James
is
not
that
big
a
deal
in
terms
of
flight
traffic.
You
know
Pi
Pio
studies,
fastly
and
I.
Imagine
that
they
would
be
in
a
similar
boat
of
mining
to
be
a
CDN
friendly
as
possible.
C
Right
yeah,
it's
a
lot
of
things
that
rhyme
I'm,
gonna
suggest
actually
I
know.
This
is
annoying
but
I'm
going
to
suggest
that
you
make
another
appearance
at
the
next
call
sure
February
9th,
just
so
that
Emir
friendly
tends
to
catch
a
few
more
people,
definitely
I
usually
see
npm
folks
there,
so
it
is.
It
is
an
unusually
light
turnout
today.
B
Yeah,
no,
no
problem,
yeah
and
yeah
just
wanted
to
get
feedback
start
sort
of
bringing
up
some
of
this
stuff,
because
this
was
something
that
was
brought
up
in
the
salsa
tooling
meeting
recently,
which
was
people
are
starting
to
publish
their
stuff
to,
let's
say
right
now,
let's
say
GitHub
right,
but
even
among
GitHub
releases.
Nobody
really
has
a
pattern
for
like
well
how?
What?
Where
should
this
salsa
actually
live?
Should
it
live
under
like
this
piece
of
releases?
Should
it
just
be
a
flat
file?
B
Should
I
you
know,
and
then
you
know
folks
I
think
are
gonna,
be
asking
for.
You
know
some
some
basic
functionality
here
and
there
just
so
that
you
know,
as
they
download,
for
example,
a
something
like
it,
whether
it's
a
ruby,
gem
or
or
whatever
they
want
to
know
like
I.
You
know
it
doesn't
have
to
literally
live
inside
the
same
package.
It
could
just
sort
of
say
when
I
download.
B
This
thing
I
can
also
make
a
separate
request
here
to
pull
down
this
item
and
then,
when
I
download
the
package
I
can
compare
the
hashes
whatever
like
I.
Think
it's
just
right.
Now
a
lot
of
interest
in
sort
of
trying
to
figure
out
some
of
those
things
before
everybody
starts
Distributing
you
know,
starts
generating
salsa
attestations
and
has
bombs
everywhere
because
then,
as
soon
as
they
do,
people
are
gonna
say
great.
You
know,
just
as
it
hit
like
npm
uses
this
API
that
the
rest
API
this
other
one
uses
this.
B
You
know
a
soap
API
or
whatever
you
know,
everybody's
starting
to
use
very
different
things
very
different,
nouns
and
verbs,
and
then
before
you
know
it
like
okay,
great
I'm,
somebody
who
is
you
know
maintaining
some
thing
that
interacts
with
both
Ruby.
You
know
both
Ruby
and
python,
but
I
need
to
now
Implement
completely
different
things
for
those
two
ecosystems,
as
opposed
to
oh
generally,
they're
following
this
specification.
So
as
long
as
I
follow
that
specification,
I
know
I
could
at
least
get
this
Baseline
level
of
thing.
E
I
I
have
one
minor
question,
so
one
thing
I
didn't
understand:
the
API
will
give
us
access
to
salsa
attestation
or
a
Spam
documentation.
So
I
was
wondering:
do
we
have
any
source
that
where
maintenance
are
generating
those
at
them
or
they
have
those
as
well,
and
they
will
share
it
with
that
API
or
is
it
something
just
to
have
the
API?
Now
then,
once
we
will
have
large
population
generating
as
Commerce
South
Side
decision,
then
it
will
be
useful.
What's
the.
B
So
you
can
imagine
like
oh
I
I
include
the
salsa
attestation
on
just
as
an
example.
Here,
oh
I
I
include
the
salsa
attestation
in
my
GitHub
release.
Somebody
might
else
might
say:
hey,
no
I
include
this
salsa
attestation
in
this
rest
API.
If
you
need
to
hit
it
and
for
the
end
user,
you
know
they
might
say
well
great,
there's
a
lot
of
packaging
ecosystems
out
there
are
there.
Is
there
something
that
I
could
just
use?
B
That's
consistent
to
be
able
to
download
that
and
so
that,
when
so,
so,
that's
one
thing
and
so
to
to
go
back
a
little
bit
more
as
salsa
is
about
to
hit
1.0
and
s-bombs
are
growing
in
in
sort
of
popularity.
A
lot
of
folks
are
asking
like
hey
I'm,
generating
these
s-bombs.
Where
do
they
go
and
then
separately
the
people
who
are
like?
B
Oh
great,
how
how
should
they
be
consumed
is
also
I
think
those
two
things
are
very
closely
tied
and
so
it's
it
is
sort
of
a
chicken
and
egg
thing
where
we
think
that
people
are
generating
s-bombs
but
they're.
You
know
a
lot
of
folks
are
generating.
S-Bombs
are
just
saying
like
on
demand,
we'll
give
you
an
s-bomb,
but
in
addition
to
that,
a
lot
of
folks
who
are
generating
s-bombs
just
have
no
place
to
put
them
and
then
separately
the
there's.
B
The
thing
there
is
is
folks
are
starting
to
use
these
things,
but
because
there's
no
standards
and
practices
where
potentially
at
a
point
where,
like
a
lot
of
people,
are
just
gonna,
be
like
it
doesn't
pay
for
me
to
even
make
this
thing.
If
there's
no
way
to
consume
it
and
there's
going
to
be
a
lot
of
folks
who
are
saying
hey
if
I
can't
consume
an
s-bomb,
how
could
I?
Possibly
you
know,
why
should
I
produce
one
myself
that
sort
of
thing
foreign.
E
B
Yeah
and
and
so
I
think
that
thing
that
you
bring
up
so
yeah
like
there's,
there's
right
now,
I
think
what
I'm
bringing
up
here
is
is
more
focused
on
the
open
source
world
where,
hopefully,
folks
are
not
going
to
be
as
cautious
with
that
sort
of
stuff.
I
I
recognize
you
know
for
for
certain
businesses,
they're
like
hey,
we
don't
want
to
give
away
our
secret
sauce
and
we
believe
what
dependencies
we
use
to
be
part
of
that
I.
B
Don't
necessarily
agree,
but
I
I
understand
at
least
where
that
argument's
coming
from
and
it
I
think
to
that
point
actually
is
yeah.
So
there
are
a
couple
of
other
things
that
are
related
right.
Very
few
tools
actually
follow
the
spdx
or
S
form
specs
like
a
lot
of
them.
They
follow
a
lot
of
it,
but
they
actually
because
of
sometimes
it's
just
as
simple
as
a
typo
calling
this
key
a
different
key
name
and
now,
all
of
a
sudden
everything
you're
generating,
isn't
actually
valid
in
the
spec
yeah.
B
We're
definitely
noticing
a
lot
of
that,
and
part
of
this
is
part
of
that.
Like
standardized
standardization
effort,
yeah
I'm
not
super
involved
in
the
s-bomb
stuff,
outside
of
more
as
a
consumer,
but
I
know
from
the
salsa
and
we're
trying
to.
If
we
we
can
maybe
even
have
stuff
like
a
salsa
publishing
Library,
so
here's
a
library
for
generating
and
Publishing
salsa
documents.
B
So
we
don't
have
to
go
in
and
re-uh
you
know
have
it
Implement
a
separate
implementation
for
both
publishing
and
consuming
salsa
metadata,
for
you
know,
ruby
gems,
as
we
do
for
npm
and
so
on
and
so
forth
like
because
that
that
sort
of
thing
well,
you
know
having
all
those
different
implementations
can
end
up.
You
know
also
making
it
very
difficult,
then,
for
for
those
things
to
remain
consistent
to
make
them
remain
relatively
bug,
free
to
have
sort
of
a
consistent
experience
across
the
ecosystems.
C
There
is,
in
my
experience,
nothing
harder
in
the
world
to
convince
somebody
to
use
a
tool
from
another
ecosystem
and
very
often,
for
a
good
reason
right,
like
shelling
out
to
something
is
kind
of
not
it's.
It's
a
bit
black
boxy
right,
it
kind
of
interrupts
the
thing,
and
it
also
means
you
know.
You've
got
to
deal
with
the
business
of
Distributing
that
that
item
with
the
rest
of
the
software
and
blah
blah
blah
so.
B
Yeah
yeah,
that's
definitely
something
we
agree
with
I
think
we're
trying
to
keep
it
as
simple
as
possible,
and
potentially
it
also
is
not
impactful
as
possible.
Like
the
thing
you
know,
I
don't
want
to
go
too
deep
into
the
the
implementation
weeds,
but
some
of
the
things
that
people
have
brought
up
is,
it
might
just
make
sense
to
have
a
separate
rest.
Api
just
have
a
specification
for
that
rest,
API,
and
so
yes,
you
make
two
separate
requests.
B
One
request
to
actually
download
the
package,
one
request
to
download
metadata
associated
with
that
package
to
a
separate
rest
API,
but
then
it
doesn't
necessarily
really
like
you
know
you
could
still
download
the
package.
You
don't
actually
you
know,
you're
not
required
to
have
the
back
end
now
support
all
this
extra
stuff.
B
B
B
C
C
We're
talking
about
sort
of
the
question
of
how
s-bombs
and
salsa
attestations
can
be
distributed
for
package
ecosystems
and
I
was
making
the
case.
That's
something
that's
sort
of
like
an
API
based
approach,
imposes
sort
of
a
fair
amount
of
potential
load
on
the
application,
server
versus
something
where
it's
like
it.
Basically,
it's
a
path
that
can
be
served
directly
by
the
CDN,
where
we
can.
Let
vastly
worry
about
it.
C
C
F
A
F
But
let
me
let
me
say
this
Michael
from
what
I
can
say
and
what's
kind
of
going
on,
I
think
that
you
do
have
to
treat
all
of
these
things
with
the
utmost
care,
because
certain
shall
we
say
people
in
Homebrew
treat
open,
source-like
religion.
So
when
you
start
talking
about
security
and
implementing,
you
know
things
that
you
know
should
be
done
and
are
for
the
greater
good
there's.
Always
someone
on
the
other
side
of
the
fence
that,
let
me
just
say
this.
The
word
strong
armed
was
used
a
lot
recently.
F
B
Yes,
I,
don't
know
who,
but
I
definitely
know
that
folks
from
all
the
ecosystems
and,
in
fact,
actually
I
can't
remember
who
it
was
from
Homebrew
if
it
was
yourself
or
somebody
else
who
had
said
hey
if
something
like
this
were
to
kind
of
get
done,
I
know
that
it
sounded
like
Homebrew
wanted
to
be
more
of
a
consumer
of
the
thing
they
were
like.
Look
if
other
folks
build
a
thing,
we
were
totally.
F
Down
to
be
to
be
honest,
to
actually
tell
you
where
homebrew's
position
on
this
would
be
is
like
look
if
you
want
to
come
at
them
with
money
or
like
with
the
work
or
something
along
those
lines,
they
might
be
willing
to.
Do
it.
There's
a
there
would
be
a
big
what
like
maintainer
burden.
What?
If
because
that's
kind
of
what,
apparently
it's
all
about
nowadays
is
you
know,
maintain
or
burden
this
maintain
or
burden
that
but
yeah
like
they're
they're,
very
much
they
would
be
like.
C
C
They're
not
they're,
not
going
to
sit
around
and
go
like.
Let's
discuss
this
carefully
for
a
few
months
and
take
soundings
and
really
understand
open
source
software
and
make
sure
that
we
come
to
a
meeting
the
minds
they're
just
going
to
flick
the
table
and
regulate
the
out
everything
and
they're
going
to
invite
they're
just
going
to
like
turn
those
licenses
into
you
know,
toothpaste
because
they
can
right
copyright.
F
F
If
I,
if
I,
can
add
to
that
drug,
that
I
kind
of
presented
somewhat
of
a
similar
point
during
our
discussions
this
week
and
somebody
decided
we're
not
going
to
point
fingers,
but
let's
just
say
that
somebody
in
the
room
decided
to
start
trolling
going
well.
That's
not
my
government
and
I
was
like
this
is
just
not
a
productive
conversation.
You.
E
F
C
C
F
So
yeah
and-
and
it
was
one
of
those
things
that
Homebrew
maintains
that
we
are
not
a
security
system.
Do
not
take
us
as
like
a
security
defense,
because
we're
not
and
we'll,
like
you
know,
disavow
all
knowledge,
all
responsibility,
but
yeah
I.
Think
that
that's
also
important,
maybe,
though,
to
distinguish
because
it
is
true
like
like
there
are
different
mentalities
when
you're
dealing
with
developers
and
people
that
download
things
and
hey
it
should
work
and
it
should
be
relatively
safe
because
if
not,
they
wouldn't
carry
it
they're,
not
that
bad.
C
Yeah,
as
I
said,
I
I,
yeah,
so
I
studied
Laura
for
a
few
years
and
and
like
I,
can
tell
you
that
toilets
is
a
mind
twister,
but
the
way
the
chords
can
find
to
pin
something
to
you
that
you
did
everything
in
your
power
to
to
lay
off
right.
You
wrote
contracts,
you
got
agreements,
you
created
trusts,
you
had
corporations
and
llc's
and
all
that
jazz
and
somehow
the
quad's,
just
like
not
you
are
responsible,
yeah
I
I
would
be
more
nervous
in
that
position.
F
C
C
C
We
had
a
meeting
which
was
organized
by
John
Meadows
from
the
end
users
working
group.
The
subject
was
a
topic.
That's
come
up
here
a
few
times,
which
is
the
need
or
the
want
for
a
collection
like
a
central
collection
Point,
partly
for
useful
basic
metadata
on
packages,
but
also,
and
especially,
a
controlled
Corpus
of
Mount
West
samples.
C
At
the
moment,
when
something
is
reported
to
a
package
ecosystem,
they
yank
it,
it
gets
deleted
and
there's
no
sample
available
for
study
by
you
know
qualified
and
and
identified
researchers.
So
the
main
thing
that
sort
of
came
out
of
that
I
would
say
actually
I
kept
notes
on
it,
which
I'm
going
to
pull
up
on
my
screen
over
here,
they're
sort
of
notes,
mostly
for
internal
consumption,
so
I
can't
share
my
screen,
unfortunately,
because
then
I'd
be
sort
of
showing
off
all
this
other
stuff
that
we're
doing
that's
private.
C
C
So
a
big
thing
that
the
open
ssf
can
do
is
to
bring
money
to
the
table
either
to
offer
contracts
or
grants
to
subsidize
the
work
and
that
we
should
try
to
start
small
rather
than
sort
of
planning
to
do
everything,
because
there's
a
lot
of
things
that
spin
off
from
the
original
idea
that
are
possibilities.
You
know
we
could
do
this
and
we
could
tie
it
into
threat,
intelligence
and
analyze,
trans
and
spotted
taxes.
E
C
C
Okay,
well,
there'd
be
no
other
business
tonight.
What
I'm
going
to
do
is
let
folks
leave
early
and
get
their
evenings
back
for
those
of
us
who
are
not
in
APAC
times
and
to
get
some
morning
time
back
for
those
who
are
thanks,
everybody
for
coming.
Our
next
meeting
is
on
February
9th.
That
will
be
the
Emir
friendly
time.
So,
if
you're
an
APAC
a
bit
rough
but
for
those
of
us
in
the
United,
States
or
Europe,
probably
a
little
easier
until
then,
it's
been
wonderful
and
we'll
see
you
all
next
time.