►
A
A
A
A
A
A
D
E
A
F
E
All
right,
let's
go
and
get
started
with
introduction,
so
yeah
welcome
anyone,
that's
new!
This
is
a
working
group
about
software
repositories.
We
have
a
lot
of
folks
from
different
places
in
the
ecosystem
we
started
coming
together.
I
work
on
similar
problems
here,
kevin
real
quick.
Do
you
want
to
introduce
yourself.
G
G
G
E
B
I
E
B
J
True,
I'm
drew
davidson,
I'm
a
professor
at
the
university
of
kansas.
We
had
gotten
involved
in
openssf
kind
of
at
the
recommendation
of
the
google
open
source
security
team
and
initially
had
joined
the
identifying
security
threats.
Working
group,
along
with
my
colleague,
lorenzo
decarly,
and
one
of
the
outcomes
from
that
group
was
so.
We've
done
this
previous
work
on
package
security
and
sort
of
studying
package
ecosystems,
which
is
work
that
we'd
like
to
continue
doing
so.
It
seemed
like
this
would
be
a
good
group
for
us.
J
We
are
also
trying
to
get
together
a
little
survey
of
the
problems
that
happen
in
security
reports
like
essentially
when
someone
mentions
that
there's
a
vulnerability
in
a
package
and
sort
of
what
the
best
practices
are
for
that,
and
especially
what
behavior
crosses
the
line.
So
that's
kind
of
our
whole
deal.
K
B
E
Okay,
so
roughly,
how
is
the
work
we'll
go
over
action
items
from
our
last
meeting
real
quick?
We
have
a
full
agenda,
so
I'm
gonna
ask
everyone
to
have
something
on
the
agenda.
Just
please
be
mindful
of
time,
so
we
can
get
to
everything,
real,
quick
on
the
action
items.
First
thing
our
emea
friendly
meeting,
which
will
take
place
in
two
weeks
from
now
we're
going
to
shift
the
time
slightly
more
friendly
to
folks
in
the
u.s
and
elsewhere.
E
So
there's
a
poll
please
make
sure
I'll
highlight
that
in
this
comment
here,
there's
a
form
I
also
shared
it
in
the
slack.
Please
just
fill
that
out.
There's
a
couple
times
in
there
that
we're
going
to
shift
to
also
I
talked,
I
would
externalize
a
doc
on
testing
six
door
and
tough
clients
that
dock
is
now
available.
That's
here
you're
welcome
to
follow
that
and
I'll
probably
want
to
discuss
that
in
the
follow-up
meeting.
I
will
also
share
that
link
out
more
widely
as
well.
D
Oh
yeah,
I
guess
just
a
quick
update,
well
more
of
a
thanks
for
those
that
other
than
we
have
a
couple
new
columns,
I'll
socialize,
just
a
little
bit
more
coupon
next
week.
I
think
the
plan
after
that
is
we'll.
Do
the
blog
post
extend
this
a
little
bit
further
and
then
kind
of
start
to
condense
and
figure
out.
You
know
more
granular
roles,
so
it's
easier
to
compare.
B
E
E
Azer's!
Not
here.
I
haven't
seen
anything
about
this,
but
I'd
still
like
to
get
this
sort
of
cleaned
up
and
shared
with
everyone.
So
we'll
work
on
that
miles
is
also
cannot
make
it
today.
So
he's
not
here
and
zach.
I
think
resolve
these
two
actions,
so
I
think
we're
good.
Is
there
anything
I'm
missing.
F
Yeah
g'day,
so
two
folks,
mislove
and
lorenzo
raised
in
the
general
channel
of
the
open,
ssf
slack
that
it
would
be
nice
if
they
could
get
their
hands
on
no
malicious
packages
without
a
bunch
of
hoopla
and
trouble.
It
seems
like
a
really
good
match
for
the
existing
proposal
to
collect
data
about
different
repository
systems
like
they.
They
seem
like
peanut,
butter
and
chocolate.
As
the
saying
goes,
so
I
wanted
to
bring
that
to
folks
attention.
F
I
I
don't
actually
have
an
answer
to
the
question
you
were
trying
to
ask.
I
was
just
gonna,
because
the
comment
has
been
added
here
about
the
blog
post
in
our
package
analysis
project.
We
have
thought
about
doing
this
in
the
future,
particularly
either
attaching
it
to
the
package,
analysis,
project
or
the
package
feeds
project.
I
The
yeah
like
there's
a
kind
of
scale,
to
making
sure
we
can
store
everything
and
make
it
accessible,
but
it
is
something
that
we're
very
much
interested
in
as
well
so,
but
like
we're
in
a
position
with
the
projects,
we
have
to
be
able
to
do
that
and
certainly
doing
it
in
a
central
place
so
that
other
people
can
build
on.
It
is
a,
I
think,
a
valuable
idea
as
well.
D
Oh,
I
wanted
to
add.
I
think
there
was
an
issue
for
apple
shack
and
a
couple
of
us
are
kind
of
looking
at
it
that
was
kind
of
looking
more
at
keeping
track
of
all
the
different
compromises,
so
we're
creating
a
data
model
for
that.
So
I'm
wondering
whether
you
would
see
this
as
part
of
just
general
compromises
or
would
be
a
separate
thing.
That's
worth
keeping
a
separate
database
for.
F
F
B
H
I
just
want
to
say
I
think
first
priority
here
is
just
making
sure
we
retain
these
packages
and
don't
you
know
shred
them
off
the
face
of
the
earth
and
then
everything
after
that
is
is
bonus
just
because
I
I
think
the
status
quo
is,
if
we
find
a
package
to
be
malicious,
we
want
to
eradicate
all
traces
of
it
and
so
having
policies
in
place
where
we
don't
do
that
is,
is
to
me
the
the
biggest
win
and
format,
etc
can
be
hashed.
Out
later,
I
see
drew.
J
As
a
hand,
yeah
I
mean
just
like
I
guess,
representing
our
own
academic
research
interests
here,
I'll
say
that
just
in
terms
of
format,
we'd
like
to
see
as
much
metadata
preserved
as
possible
as
well.
You
know
we're
already
interested
in
things
like
what
is
the
popularity
of
packages
at
the
time
they
were
deemed
malicious.
What
was
the
name
of
the
package?
A
A
E
K
Yeah,
so
in
response
to
the
questions
that
were
posed
on
the
general
channel
the
other
day,
I
realized
that
activestate
has
been
active,
actively
mirroring
a
number
of
upstream
repositories
for
quite
some
time.
We
mirror
on
a
daily
basis,
so
anything
that
comes
and
goes
within
four
hours
we
may
miss,
but
we
generally
tend
to
get
everything
that
sticks
around
for
more
than
24
hours.
K
So
we
are,
might
we
are
mirroring
currently
pipeyi
cpan,
rubygems
and
packagist,
and
we
are
going
to
start
shortly,
mirroring
npm
as
well,
and
I
just
figured
it
would
be.
As
we
have
all
this
stuff,
we
tend
to
remove
it
from
our
catalog
so
that
you
can't
actually
add
it
into
projects
that
you
build
on
the
active
state
platform,
but
we
still
keep
the
source
code
around
and
we
still
still
keep
the
metadata
around.
It's
just
not
actively
available
to
use
in
to
use
in
builds.
K
K
K
K
K
K
More
repository
information
and
the
description
and
publishing
date,
and
things
like
that,
so
those
are
things
that
can
be
added
in
fairly
easily
and
I
will
work
on
trying
to
get
those
in
but
yeah,
just
as
a
first
step.
If
you
need
access
to
anything,
that's
been
published
in
the
last
three
or
four
years,
I'm
from
pipei
and
cpan
and
probably
the
last
year,
18
months,
ruby,
gems
and
packages
that's
been
removed
from
the
upstream
repos.
We
have
a
copy
of
it.
E
K
K
Yeah,
that's
that's
part
of
the
reason
that
we've
said
in
the
in
the
documentation
there
that
one
of
the
things
we're
going
to
do
is
lock
down
these
apis
so
that
one
it's
only
authenticated
users
who
can
use
it.
Two
will
be
restricting
access
to
things
that
we
are
that
were
publicly
available
as
malware.
Only.
K
K
E
I
I
was
just
going
to
quickly
say
like
in
reality,
pipeline
doesn't
actually
disappear.
Any
files
so
like
this
one,
for
example,
does
exist
on
disk
somewhere
that
I
could
give
you
a
link
to
it's
not
easily
discoverable,
but
I
think,
and
I'm
curious,
if
that's
the
case
for
some
of
the
other
ecosystems
as
well.
J
I
mean
I'll
say
kind
of
echoing
the
previous
points
that
it
is
quite
difficult
in
my
experience
to
get
track
of
npm
packages
that
have
been
taken
down,
so
I
can
only
speak
to
that
repository
and
then
my
question,
I
guess
to
keep
the
mic.
Is
a
lot
of
repositories,
keep
track
of
these
like
usage
statistics,
weekly
downloads?
That
kind
of
thing
do
you
know
if
any
of
that
data
is
scraped,
it
may
not
even
be,
I
suppose,
available
from
the
source,
repo.
K
We
tend
to
keep
metadata
that
doesn't
change
over
time
about
these
things,
but
we
are
starting
to
track
metadata.
That
does
change
over
time
so,
for
example,
cves
so
yeah.
When
we
do
our
initial
ingestion,
we
don't
currently
track
things
like
usage
or
popularity,
but
we
will
take
any
metadata
that
was
available
at
the
time
of
publishing.
K
E
E
I
think
probably
most
folks
have
seen
there
is
some
recent
discussion
about
npm
and
takeovers
of
you
know,
custom
domains
and
things
like
that.
Gaining
access
to
accounts-
and
so
I
was
hoping
mpm
folks-
would
come,
be
able
to
join
us
and
have
participate
in
this
discussion.
But
I
kind
of
just
get
folks
thoughts
a
little
bit
for
a
couple
of
minutes
on
what
could
actually
be
done
to
counter
a
domain
expert
attack
and
for
anyone
not
familiar.
What
happened?
Is
you
know?
E
You
know,
aside
from
like
running
a
like
a
a
registrar
or
something
that
has
like
immediate
access
to
the
status
of
every
domain,
and
you
know
insight
into
who
owns
it
and
if
the
ownership
is
transferred.
I'm
curious,
like
what
other
ecosystems
have
done
here.
There's
I
can
talk
about
some
things
that
pipeli
has
done,
but
I
kind
of
want
to
open
the
floor
to
anyone
else.
B
L
Eddie
yeah,
this
is
so
in
the
go
world
we
have
lots
of
vanity
domains
that
you
know
are
just
pointing
to
a
github
repo
redirect
and
we've
talked
about
this
a
few
times
on
the
kubernetes
project
and
it
it's
kind
of
scary.
I
don't
know
if
we
have
any
actual
mitigations
in
place
other
than
we
render
all
of
our
dependencies
and
make
sure
all
the
checksums
match
before
we
do
anything.
But
yeah.
That's
definitely
come
up
a
few
times
in
the
kubernetes
world.
M
Yeah
we've
been
talking
about
this
a
lot
as
well,
and
you
know
we
we
have
domain
based
sort
of
validation
of
these
name
spaces,
but
you
know,
they've
been
central
has
been
around
now
for
like
15
years
or
something
right.
So
we
know
a
certain
release
is
expired
right
and
we
definitely
want
to
revalidate.
You
know
those
name
spaces
and
thinking
about
how
to
approach
that
you
know,
like
deactivating,
making
registration
happen,
prevent
the
kind
of
attacks.
M
The
other
thing,
though,
is
just
kind
of
understanding
the
impact
a
little
bit
right
like
this.
You
know
something:
that's
that's
old,
with
an
expired
domain
like
how
many
things
are
really
dependent
upon.
That's
right.
How
to
better
understand
like
what
the
impact
of
these
sort
of
forgotten
you
know.
Name
spaces
are
what
dependents
are
actually
using
open-ended
version
ranges
or
latest
right,
so
that
this
attack
you
know
versus
specifying
a
particular
version
right-
is
a
build,
so
there's
kind
of
some
some
more
research.
M
E
A
Just
real
quick
somebody
said
vanity
domains
and
I
see
the
note
says:
custom
domains.
I
appreciate
the
they
switch
over
because
speaking
of
someone
who
uses
a
custom
domain
routinely
and
I
have
switched
my
mail
providers.
I
have
had
three
different
mail
providers,
so
there
are
advantages
to
the
custom
domains.
You
can
actually
control
it
and
that
sort
of
stuff,
so
there
are
for
those
of
us
who
are
doing
it.
A
We
have
a
reason
for
it,
but
I
do
agree
with
the
problem
I
would
I
would
like
I
I
it
seems
to
me
there's
ways
to
detect
it
but
yeah.
I
think
the
fundamental
attack,
I
think,
is
basically
password
resets
and
taking
over
an
account
because
it
seems
to
be
a
domain
name,
and
you
know
it's
switched
over.
Am
I
missing
it?
Is
there
another
attack
besides
either
the
you
know,
password
reset
or
I
point
to
documentation.
This
is
the
official
homepage
of
the
project
and
whoops
I
took
it
over.
E
No,
I
think
the
main
attack
is
taking
over
the
account
of
a
maintainer
and
being
able
to
publish
new
versions
or
compromise
versions
and
yeah.
I
want
to
just
like
be
clear
that,
like
using
a
custom
domain
is
a
valid
use
case,
I
don't
think
we
want
to
just
say
get
rid
of
all
custom
domains.
That's
definitely
not
what
I'm
proposing.
F
Yeah,
I
I
I
wonder
whether
this
is
a
case
where
two-factor
authentication
gives
us
a
reasonable
defense
against.
That
kind
of
this
is
a
resurrection
attack
right
like
it
falls
into
that
that
general
class
the
same
as
usernames
that
have
been
deleted
or
packaged
names
that
have
been
deleted
and
get
reused.
So
it
seems
it
feels
as
though
two-factor
authentication
is
to
me
off
the
top
of
my
head,
the
best
defense,
insofar
as
the
odds
that
somebody
is
able
to
defeat.
E
F
In
in
the
meantime,
I
I
guess
my
my
best
guess
is
that
we
we
do
the
thing
that
I
sort
of
keep
harping
on
about
which
is
trying
to
make
the
attack
and
move
in
the
open.
This
to
me
sort
of
raises
the
question
of
whether
domain
names
changing
wants
to
become
something
that
we
write
into
a
transparency
log
as
a
security
critical
event.
B
Yeah,
the
other,
the
other
attack
vector.
This
applies
a
little
bit
to
central,
but
I
suspect,
notionally
to
others
as
well,
urls
that
are
contained
by
the
content,
the
metadata,
so
in
maven
you
know,
historical
palms
might
refer
to
other
repositories
that
were
expired.
We
went
through
this
fire
drill.
B
Last
year,
jonathan
leach
was
doing
some
work
there,
and
so
we
had
to
go
assess
all
of
the
repositories
that
were
referenced
by
all
the
palms
in
central,
and
we
found
the
couple
I
own
a
couple
domains
now
to
protect
the
world
from
those
types
of
attacks,
but
I
suspect
similar
things
might
exist
in
npm,
install
scripts
and
and
and
other
types
of
references
that
we
might
want
to
think
outside
of
just
just
the
email
address
of
the
publisher.
As
an
example.
E
I'll
just
quickly
add
the
one
thing
pipi
does
here
to
sort
of
help,
but
obviously
not
fully
protect
folks
against
this.
We
try
to
send
a
fair
amount
of
emails
to
maintainers.
You
know
when
different
activities
and
events
happen
and
if,
in
any
case,
a
email
bounces
most
likely
due
to
the
mx
record,
going
away.
We
just
unverify
that
email
address
and
it's
no
longer
a
valid
avenue
for
password
resets
until
it's
logged
in
and
re-verified
via
a
different
email
address.
E
I
I
think,
from
a
package
scanning
point
of
view,
there's
opportunities
here
in
terms
of
correlating
the
metadata
and
domains
of
the
maintainers
against
when
new
packages
are
published
and
being
able
to
detect
like
substantial
changes
to
the
dns,
but
either
the
name
servers
or
the
dns
records.
I
suppose,
as
a
as
a
signal
from
like,
is
this
malicious
or
not.
G
I
know
some
of
these
formats
already
support
that,
but
there,
of
course
it's
tricky
because
you
have
a
lot
of
individuals
and
then
you
have
to
accept
those
signatures
and
kind
of
track
the
seat.
Yeah.
Is
this
really
that
person
it's
difficult
to
do
that,
however,
you
know
with
chain
of
trust.
If
you
can
kind
of
trust
one
person
and
that
person
trusts
someone
else,
that's
another
thing
that
could
be
checked.
In
addition
to
you
know,
domains
or
email
addresses
or
something
like
that.
E
A
I
I
do
have
one
one
more
briefly,
I've
I
have
mold
around
the
idea,
and
this
is
really
for
the
very,
very
tiny
packages
like
for
each.
You
know
it
might
be
good
to
have
some
some
organization,
some
person
being
able
to
operate
as
the
second
eyeball
and
just
not
allow
publishing
without
somebody
else
checking.
E
N
N
N
N
N
Another
discussion
came
up
about
what
the
relationship
would
be
between
an
artifact
and
the
signing
certificate.
That's
used.
I
think
there
was
a
notion
at
some
point
that
that
might
be
one
to
one.
That
is
not
what
I'm
doing
right
now,
so
I
basically
cash
the
key
pair
and
the
signing
certificate
for
the
session
in
maven,
so
that
someone's
not
bouncing
out
to
oidc
like
50
times,
while
they're
doing
a
release,
but
again
how
that
actually
works
in
practice.
May
change.
N
N
N
N
But
it
goes
through
the
normal
maven
release
process
that
most
people
are
familiar
with.
It
gets
to
the
signing
part,
it
jumps
out
to
the
oidc
provider
and
at
this
point
it
caches
everything
so
that
it
doesn't
have
to
sign
or
jump
out
to
oidc
in
this
case,
probably
eight
times
if
it
had
to
that,
should
all
be
making
its
way
up
to
oss.saunatype.org.
E
N
That's
their
validation
process
will
kick
in
and
again
the
layout
that
I
have.
There
is
doing
all
of
the
the
sig
store
public
keys
or
their
the
sorry,
the
the
folgio
publix
cert
the
signature
and
then
all
of
the
pgp
signatures
that
are
required
by
maven
central
currently,
and
I
think
it
works
fine
in
a
hybrid
mode
as
more
projects
start
using
sigstor.
N
So
you
can
see
it's
rather
lengthy,
because
it
basically
is
signing
everything
that
sig
store
also
did
as
well.
But
it's
functional
passes
the
validation
it
can
be
released
into
maven,
central
and
there's
probably
some
details
to
work
out
with
brian
and
jason
and
joel.
But
if
we
figure
out
what
the
extension
should
be,
how
things
can
live
together
until
pgp
is
shed.
D
N
N
And
then
that
could
be
used
in
repository
manager,
plug-ins
or
the
build
tools
themselves
to
do
validation
in
real
time
because
they're,
that's
not
something
that's.
I
know
very
few
people
who
actually
use
the
pgp
signatures,
so
it'd
be
nice
if
it
was
actually
if
the
verification
was
actually
built
into
the
downloading
mechanism
by
default.
E
M
Yeah
thanks:
this
is
awesome
by
the
way
thanks.
You
know.
I
know
that
damien
and
herbert
have
some
verifier
code
that
they
have
a
pr
against
one
of
the.
I
can
track
it
down.
I
think
it's
on
the
the
six
store,
maven
plugin
or
something
similar
you
may
be
able
to
reuse
as
well.
They
did
some
some
validation
logic
using
the
material
from
from
sigstor
onto
that
validation.
N
L
Yeah,
so
this
came
out
of
working
with
dustin
in
the
psf
folks
last
week,
at
pycon
on
integrating
sig
store
with
pipi.
We
realized
that
all
these
awesome
people
are
going
to
be
adding
packages
to
recore
in
six
store
and
we
probably
don't
want
to
create
a
different
package
type
for
every
single
package
manager
out
there.
So
zach
proposed
the
idea
of
having
a
generic
package
type
inside
of
record
six
store
and
there's
an
issue
open
to
kind
of
get.
This
conversation
started
and
find
out
what
folks
would
like
in
there.
L
F
Jack,
yes,
I'm
against
creating
new
taxonomies
one
thing
I'd
say
is:
this
is
part
of
the
origin
story
for
this
group
is
is
coming
to
such
an
agreement
on
on
recall
types.
It's
like
one
of
the
things
I
had
in
mind
when
I
started
being
part
of
the
informal
coalescence
that
has
since
formed
into
this
beautiful
flower.
L
Yeah,
that's
definitely
something
we
can
work
in.
Is
that
the
search
through
the
different
fields
and
right
now,
it's
just
a
post
of
a
search
body,
and
you
can
basically
it's
free
form,
map
json
in
there,
so
we
can
index
on
the
the
prl
or
whatever
we
figure
out
for
that.
So
yeah
noted,
if
you
could
drop
that
note
in
the
the
thread
to
the
github
issue,
that'd
be
helpful.
Thank
you.
H
I
was
gonna
play
devil's
advocate
or
customer
obsession.
What
do
how
do
you
expect
someone
to
use
it
across
different
ecosystems
and,
if
you've,
in
as
much
as
the
format
should
stay
the
same
so
that
someone
can
use
it
across
these
different
ecosystems?
We
should
totally
make
it
standardized
and
make
that
easy
and
any
place
we're,
including
a
standard
just
so
that
we
can
have
it,
and
we
don't
know
why
someone
will
want
to.
We
should
consider
the
option
of
just
not
and
letting
different
ecosystems
use
whatever
feels
natural
to
that.
F
F
One
of
the
guiding
principles
of
this
group
has
always
been
that
it
is
not
a
governing
body
or
a
standards
body
like
we
can.
We
can
publish
what
we
think
people
should
do,
but
in
no
way
do
we
like
take
a
vote
and
then
that
binds
everybody.
If
folks
want
to
do
their
own
thing,
then
by
god
do
your
own
thing.
That's
that's
a
key
principle
because
we're
all
just
here
to
cooperate.
We're
not
here
to
like
make
each
other
do
things.
H
So
what
would
be
really
helpful
is
if
we
could,
in
the
design
of
this
articulate
a
security
researcher
who
wants
to
run
this
kind
of
query
across
these
three
ecosystems
would
be
able
to
do
it
here,
because
I
have
no
background
in
that,
and
so
I
don't.
I
wouldn't
know
that
that's
a
use
case,
and
once
you
set
it.
Yes,
it's
obviously
a
use
case
and
yeah
I
would
like
to
hook
in
so
that
they
only
have
to
maintain
one
of
those
instead
of
eight
ten
of
them.
L
Yeah,
so
this
is
to
kind
of
if
this
conversation
might
be
good
to
have
with
the
the
sig
star
community
meeting
as
well,
because
that's
what
we're
specifically
talking
about
is
types
inside
of
recore,
which
is
the
transparency
log
for
six
store.
So
I
don't
know
if
we'll
want
to
balloon
to
all
the
hundreds
of
different
package
manager
types
out
there,
so
we're
just
trying
to
find
a
nice
way
to
address,
hopefully
80
plus
percent,
of
what
everyone
needs
inside
of
recore.
So.
E
I
think
I
was
going
to
say.
One
thing
I
remember
discussing
with
you
before
was
whether
it
would
make
more
sense
to
have
a
separate
record
for
every
ecosystem
type
of
package,
which
I
think
may
be
the
better
question
for
the
issue.
So
I'd
encourage
folks
to
think
about
that
as
well
cool
all
right
for
good
to
move
on.
I
think
wrong.
One.
D
One
quick
question:
hopefully
it
won't
derail
or
whatever.
Maybe
a
philosophical
type
question
is:
what
do
we
all
agree
on?
What
a
package
is
like
what
package
means
in
terms
of
like
when
I
look
at
the
pearl,
like
I'm
all
on
board
with
a
pearl
like
it's
the
best
thing
I've
seen
in
terms
of
options
but
like
for
maven
gradle
java
ecosystem,
a
package
is
like
a
gav
and
there
are
multiple
artifacts
that
go
along
with
that
and
those
can
maybe
be
represented
as
like
parameters
whatever
off
of
the
pearl
spec.
D
F
Lately
in
my
career,
it's
not
a
thing
I
would
have
thought
of,
and
it's
like
literally
the
kind
of
question
that
we
need
to
sort
out
if,
if
it
is
at
all
tractable
to
have
like
a
I'm,
not
going
to
say
lowest
common
denominator,
but
like
a
minimum,
viable
package
definition,
we
need
to
sort
of
like
talk
about
these.
What
I
call
architecture,
busters
things
just
swing
in
and
smash
a
wall
and
to
make
sure
that
we
can.
We
can
strike
a
commonality.
M
Yeah,
sorry,
I
I
know
you
kind
of
want
to
move
on,
but
a
comment
too.
I
mean
I.
I
just
expect
that
you
know
having
you
know:
recore
support
every
package
type
and
every
variation
of
this
is
is
kind
of
like
a
non-starter
right.
Like
I
mean
you
could
try
to
do
it
right,
but
it's
gonna
be
a
constant
churn.
There
I
mean
the
way
I
was
envisioning.
M
This
was
more
hey,
there's
some
basic
capabilities
within
record
and
six
store,
and
then
many
ecosystems
would
you
know,
hey
we're
gonna,
sign,
xyz
and
expose
those
sort
of
things,
and
you
can
go
validate
those
signatures.
You
know
using
sigstor
right,
which
is
which
is
ultimately
what
happened
someone's
gonna.
Do
that
anyway,
right
you
know,
and
so
so
you
know
kind
of
that
this
general
way
to
to
just
kind
of
hey.
M
What's
the
bare
minimum
and
letting
package
ecosystems
kind
of
you
know
supplement
that
you
know
seems
to
be
like
more
realistic
right,
because,
ultimately,
that
balconization
will
happen
regardless
right
and
trying
to
keep
up
with
all
the
various
package
formats
and
types
is
starting
with.
That
seems,
seems
kind
of
nuts
to
me.
You
know.
F
Very
briefly,
yes,
I
guess
I
would
frame
it
as
we
would
be
agreeing
on
a
base,
type,
yeah
and,
and
then
that
would
be
extended
by
ecosystems.
That's
made
sense
for
them
got
it,
so
there
would
at
least
be
some
fields
in
common.
Ideally,
but
like
things
things
that
only
make
sense
to
java,
then
it
should
be
fine
for
java
colon
etc
to
to
do
their
own
thing.
On
top.
C
Yeah
hi
hi
everyone,
so
I've
been
working
with
the
other
open,
safe
working
group
on
best
practices,
and
we
have
a
draft
for
npm
security,
best
practices
with
a
focus
on
supply
chain
and
for
anyone
who
is
interested.
We
are
looking
for
feedback
and
comments.
So
if
you
click
on
one
of
the
links,
the
npm.md
in
the
dock,
you
can
create
issues
and
and
add
comments
about.
C
C
B
Well,
have
you
had
discussions
with
anybody?
I
didn't
pm
about
this,
yet
I
just
dropped
this
into
one
of
our
internal
channels
right
now,
because
I
hadn't
seen
it,
but
I
was
just
curious
if
you're
talking
to
anybody,
I
could
have
yet
yeah
thanks
all
right.
Are
you
you're
not
speaking
with
anybody?
You
have
yet.
C
C
E
E
I
think
it
would
be
kind
of
nice
for
us
to
put
together
at
least
sort
of
a
rough
outline
of
the
different
domain.
Experience
attack
countering
mechanisms.
I
don't
know
what
to
call
it.
Just
some
of
the
stuff
that
we
described
here
and
how
that
might
affect
the
different
repositories,
and
I
think
miles
has
maybe
some
input
here
or
other
folks
from
npm
might
have
some
input.
So
I'd
like
to
just
be
able
to
sort
of
collaborate
on
something
there.