►
From YouTube: TAG Security Supply Chain WG 2022-01-06
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
we
can
get
started
as
people
join,
they
can
join
so
just
yeah.
As
a
reminder,
you
know
this
meeting
is
under
the
cncf,
which
means
that
your
participation
should
abide
by
the
cncf
code
of
conduct
and
we
can
get
started
so
well.
First
off,
I
want
to
wish
everybody
a
happy
new
year.
A
Hope
everybody
if
they
got
a
break,
had
a
good
break
and
yeah,
so
so
a
couple
of
housekeeping
things.
I
know
that
there's
been,
you
know.
I
know
a
lot
of
folks
are
asking
hey
where's
the
reference
architecture.
What
happened
with
with
all
that
it
does
seem
like
I
through
a
combination
of
some
oh
another
thing
I
forgot
to
mention
is
the
meeting
is
being
recorded,
and
so
it
will
be
uploaded
to
youtube
some
point
shortly
after
this.
The
meeting
ends.
A
So
there
was
some.
I
don't
know
if
it
was
miscommunication
or
there's
some
stuff
with
between
the
us,
thanksgiving
holiday
and
and
new
year's.
A
lot
of
folks
in
the
cef
were
on
vacation
and
and
whatnot.
So
we
wanted
to
get
the
draft
ready
for
review,
but
we
wanted
that
draft
sort
of
cleaned
up.
A
A
little
bit
because
in
in
previous
sort
of
white
peer
work
that
we
had
done,
we
wanted
to
stop
or
sorry
we
wanted
to
prevent
as
much
like
typo
related
comments
in
the
document,
and
we
wanted
folks
to
really
focus
on
the
content
and
and
that
sort
of
thing.
So
this
time
we
were
doing
that
so
most
likely
the
the
draft
will
be
going
out
either
end
of
this
week
or
early
next
week.
A
So
andres
is
cleaning
up
because
the
sorry
I
should
say
that
the
the
technical
one
of
the
cncf
technical
writers
is
still
on
vacation.
So
andres
is
just
cleaning
up
the
doc
a
little
bit
more
and
is
going
to
be
publishing
it
as
a
pdf
and
going
to
be
sending
it
out
to
the
the
mailing
list
and
out
on
twitter
as
a
call
for
public
comment
within
the
next
few
days
early
next
week.
A
That
sort
of
thing
so
just
to
give
folks
an
update
just
so
that
you
know,
you
think
that
it
just
kind
of
disappeared,
and
I
know
we
we
reckon
we
all
recognize
that
we
want
to
kind
of
get
this
out
sooner
rather
than
later,
especially
given
that
there's
a
lot
of
different
projects
and
groups
that
are
starting
to
even
cite
the
the
google
doc
draft,
and
we
want
to
make
sure
that
we
can
kind
of
turn
it
into
something
real
and
and
get
ready
for
a
release
around
kubecon
valencia.
A
So
that's
the
big
update,
wanna
just
sort
of
go
around
the
go
around
the
group
a
little
bit
and
see
if
anybody
else
had
any
sort
of
big.
I
know
we
haven't
had
a
meeting
since
mid-december
want
to
see
if
anybody
had
any
updates
any
big
things
that
they
wanted
to
discuss.
B
Folks,
sorry,
I
was
realizing
my
anyway.
The
mute
button
is
always
the
fun
one.
I
was
curious.
I've
been
watching
like
these
conversations
around
wrote
the
what
goes
into
an
s
bomb.
What
goes
in
the
scan
result,
the
intermixing
of
those
and
some
other
pieces
kind
of
like
the
roles
and
responsibilities.
B
A
Sure
so
I
know
that's
one
of
the
topics
we
do
want
to
discuss
this
year.
That's
a
big
thing
from
from
my
that's
a
big
old
question.
From
my
perspective,
I
know
that
there's
a
lot
of
open
issues
in
the
various
s-bomb
formats
as
well
as
salsa
as
well
as
in
toto
around.
A
You
know
what
fits
where
in
in
the
picture,
because
there's
a
lot
of
different
formats,
there's
a
lot
of
different
frameworks
and
specifications,
and
I
know
one
of
the
big
things
that
that
we
want
to
really
address-
or
at
least
I
want
to
address,
is
the.
How
do
we
make
some
of
these
things
a
little
bit
better
in
specifying?
A
What
am
I
not
claiming?
So
what?
What
sort
of
specific
things
in
a
at
a
station
in
s-bomb?
You
know
like
as
an
example
right
if,
if
my
s-bomb
is
just
looking
at
operating
system
packages,
can
I
specifically
say
this:
s-bomb
only
includes
operating
system
packages,
it
does
not
include,
you
know,
dependency,
libraries
and
those
sorts
of
things,
and
that's
all
I'm
claiming
in
there
how?
A
What
sorts
of
things
can
we
we
do
just
to
help
out,
because
I
think,
as
we
go
through
and
begin
to,
audit
and
whatever
we
just
want
to
have
a
better
idea
of
what
who's
claiming?
What?
When
so
that,
so
that
we
know
what's
in
there.
But
that's.
B
Interesting,
what
actually
kind
of
went-
so
I
I
was
thinking-
is
an
s-bomb
related
to
what
went
into
the
package
and
the
scan
result
is
an
opinion
based
on
time,
you're
actually
bringing
up
another
interesting
pivot.
That
says
what
is
the
scope?
Not
just
the
scope
of
the
s
bomb
from
an
opinion
based
on
vulnerabilities
and
other
things,
but
I'm
not
even
trying
to
do
anything
more
than
this.
B
A
Yeah
and-
and
actually
it
was
something
that
was,
I
think,
interesting-
that
that
some
of
the
anchors
sift
folks
had
brought
up
in
yesterday's
meeting
in
the
open
ssf.
A
Was
you
know
what
sorts
of
things
like
you
know,
they're
using
some
heuristic
models
for
certain
things
right
where,
where
maybe
it
doesn't
make
sense
to
sort
of
have
it
baked
right
into
the
build
tool
and
those
sorts
of
things
or
where
you
don't
have
access
to
the
build
tool?
And
you
still
want
to
get
a
reasonable
idea
of.
What's
in
a
you
know,
a
directory
or
container
image,
and
I
think
one
of
the
things
that
you
know
is
kind
of
lacking
is
like
how
do
we
say?
Hey
look
we're
just
looking
at.
A
What's
in
the
image,
we're
not
you
know,
looking
at
what's
actually
happening
in
the
build,
so
just
understand
that
that's
how
that
model
works,
and
I
think
even
just
sort
of
specifying
some
of
that
information
is-
is
hugely
important,
so
that
when
I
go
back
and
look
at
it,
I
know
yeah.
A
What's
the
scope
of
a
thing-
and
I
think
you
do
bring
up
a
good
point,
though,
where
there
is
currently
some
overlap
between
the
different
domains
right
now,
I
know
a
lot
of
folks
are
asking
like
hey:
where
does
the
s-bomb
end
and
something
like
a
build
attestation
begin?
Where
does
a
you
know
like?
A
A
This
is
what
we
detected
at
this
point
in
time
when
we
built
the
tool
or
when
we
you
know,
ran
the
actual
sort
of
scan
of
the
thing,
but
I
think
there's
a
lot
there
that
still
needs
to
sort
of
to
your
point
needs
to
be
sort
of
figured
out,
and
at
least
from
you
know
my
perspective,
mostly
acting
as
a
consumer
of
a
lot
of
this
stuff
is.
I
just
want
to
have
a
good
idea
of
what's
in
what
what
the
tools
that
are
generating
this
stuff,
all
this
data?
A
What
are
they
actually
claiming?
And
it's
okay
for
me
right
now.
If
there's
some
overlap,
if
in
the
next
you
know
year
or
two
it
all,
you
know,
eventually
things
get
sorted
out.
I
to
take
this
back,
I
I
don't
want.
I
don't
want
to
make
a
claim.
Like
hey
look,
you
know
everybody
should
be
doing
everything,
but
I'm
okay
with
a
little
uncertainty
if
it
gets
some
of
this
data
in
in
folks
and
sooner
rather
than
later,
if
that
makes
sense.
B
That
makes
perfect
sense
and
the
reason
I'm
bringing
it
up
here
is.
You
know
this
has
been
to
your
point
of
the
papers
and
the
guidance,
and
you
know
it's
never
of
it.
You
shouldn't
do
x,
it's
here's.
What
we're
thinking
and
having
because
it
was
the
this-
has
been
developing
for
a
while
we've
seen
what
cyclone
dx's
opinion
is
on
some
of
these
versus
spdx
and
then
the
anchor
thing
yesterday
kind
of
just
reinforcing
even
some
internal
conversations
we're
having
in
microsoft.
B
So
I've
started
writing
a
paper
on.
You
know
an
opinion
of
roles
and
responsibilities
that
I'm
happy
to
share
and
hear
so
if
others
want
to
collaborate
on
it,
that
was
kind
of
why
I
was
thinking
because
I'm
seeing
us
starting
to
shift
into
building
tools-
and
I
think,
there's
having
some
of
these
boundaries
kind
of
defined
will
help
but
also
say
here's
a
here's.
B
What
we
think
is
a
boundary
is
that
the
right
boundary
and
one
of
the
the
perfect
example
you
bring
up
is
when
I
build
a
thing:
are
there
volume
and
if
I'm
trying
to
build
an
s
bomb,
is
what
I'm
building
a
thing?
Do
I
capture
what
is
viewed
as
vulnerabilities
and
the
article?
I'm
writing.
I
kind
of
used
asbestos
as
an
example
in
the
50s
to
80s
asbestos
you
advertised
as
the
best
practice
for
you
know
securing
from
fire
in
the
theater.
B
So
at
that
point
you
could
argue
you
were
looking
for
the
inclusion
of
asbestos
in
your
in
your
bomb
as
a
best
practice
and
then,
after
that
it
became
so
bad.
It
was
an
exclusionary
thing,
so
that's
part
where
I
struggle
a
little
bit
around
s-bombs.
Is
it?
Is
it
a
factual
list
of
what
in,
as
opposed
to
an
opinion
of
what
we
think
it's
good
or
bad?
A
Yeah
definitely
interested
right.
C
Yeah,
I
was
gonna
say
my
own
take
is
that
I
would
want
to
have
the
small
as
best
as
possible
to
be
the
static
factual.
What
you
know
is
in
there
that
act.
You
know
here
are
the
packages,
not
here
the
vulnerabilities
on
the
packages,
but
I
know
we've
also
been
looking
at
not
just
the
s
bomb
on
what
we're
building,
but
also
the
build
infrastructure
itself
might
be
its
own
s
bomb,
the
some
of
our
opportunities
they're
going
to
bring
in
their
s
bombs,
we're
going
to
fan
those
and
merge
them
together.
C
B
Correct
that's
kind
of
another
pivot
of
what
michael
was
talking
about
with
the
scope,
I'm
only
trying
to
do
packages.
Well,
maybe
this
s
bomb
is
only
about
the
build
environment,
because
I
want
to
know
what's
what's
actually
on
that
machine,
because
later
it
turns
out
that
you
know
that
machine
was
built
with
peanut
butter
and
it
turns
out
it's
bad
for
some
people.
B
Okay,
I
I
will
get
that
out
what
what
is
work
best
for
folks
here,
a
hack,
doc,
google
doc
or
you
know
I
just
do
you
guys-
have
an
opinion.
What's
worked
best
for
you
guys
on
this.
A
I
I
don't
think
we
necessarily
have
opinions
some
people
post
it
on
their
personal
blog.
Some
people
post
put
it
in
a
google
doc
and
share
with
the
team
a
gist,
a
github
repo.
It
doesn't
matter.
B
A
Cool
yeah,
so
the
only
so
one
other
thing
I
wanted
to
add
on
there,
which
is,
is
something
that
I
know.
I
think
that
there's
more
than
enough
various
working
groups
and
we're
all
kind
of
in
a
million
meetings,
as
is,
but
I
know
that
there's
also
been
some
discussion
around.
A
Maybe
even
getting
some
of
the
folks
between
you
know
who
are
working
on
some
of
the
s-bomb
specifications
and
the
in
toto
specifications
and
salsa,
and
you
know
a
lot
of
the
other
sorts
of
frameworks,
standard
specifications
cetera
to
to
start
to
kind
of
talk
through.
I
think
one
of
the
big
things
regardless
that
that
is
a
very,
very
big
open
problem,
is
the
one
around.
A
How
do
we
accurately
reference
artifacts-
and
I
use
that
term-
very,
very
broadly
here,
where
the
artifact
could
literally
be
a
piece
of
software
or
the
artifact
could
be
some
other
metadata
like
another
attestation
or
an
s-bomb
or
whatever?
How
do
we
accurately
do
that
so
that
when
somebody,
let's
say
pulling
an
attestation,
maybe
they
want
to
say?
Oh
this
reference
like
this
attestation
is
making
a
claim
and
the
proof
of
that
claims
or
the
materials
related
to
those
claims.
A
One
of
the
materials
is
an
s-bomb
okay.
Let
me
pull
that
down
for
an
audit
or
whatever
right,
like
there's
some
things
there
that
are
kind
of
missing,
and
I
know
one
of
the
big
things
is
like
you
know
whether
it's
a
package
url
or
or
you
know,
using
oci
content
descriptors
or
using
any
of
the
other
things
that
that
people
are
talking
about.
A
There,
I
think,
is
something
that
is
also
going
to
be
coming
up,
probably
in
the
coming
weeks
as
things
that
people
are
going
to
start
trying
to
really
talk
through,
because
I
know
one
of
the
big
things
that's
happened
as
people
have
begun
to
generate
s-bombs
generate
these
attestations
starting
to
follow
some
of
these
best
practices.
A
They
say.
Okay,
great.
I
have
a
lot
of
this
data,
but
how
do
I
know
what
data
is
all
related
to
an
artifact
or
its
dependencies
or
whatever,
and
a
lot
of
that
sort
of
information
is
sort
of
lost
in
the
mix
right
now
and
so
there's
to
some
discussion
of
how
can
we
make
that
easier
in
some
of
these
formats?
To
start
to,
you
know
be
able
to
refer
to
some
of
that
so,
for
example,
vulnerabilities
right.
I
know
that
there's
some
discussion
yep
today.
A
It
makes
sense
to
have
asbestos
in
here
later
on,
there's
a
big
vulnerability.
Oh
no
like
it's,
probably
not
a
good
thing,
but
we
still
want
to
be
able
to
say:
okay,
well,
cool,
how
it's
it's
less
about.
Having
the
s-bomb
say,
here's
a
vulnerability,
it's
more
about
saying,
okay,
but
here's
a
unique
identifier
for
asbestos
great
now
I
can
look
in
a
database
on
an
ongoing
basis.
Hey
is
this
still
good.
Is
this
still
good
is
still?
A
Is
this
still
good
and
then
eventually
go
back
and
say:
oh
nope,
if
we
just
detected
in
you
know
something
new,
it's
no
longer
good!
Now
I
can
go
back
and
audit
all
the
things
that
have
that
unique
identifier,
but
because
I
think
today,
a
lot
of
that
sort
of
stuff
is
not
really
fully
baked
as
to
how
we
specify
it
right.
You
know,
there's
different
versions,
there's
different,
you
know,
as
an
example
is,
is
red
hat's
packaged
version
of
openssl,
the
same
literally
bit
for
bit
the
same
as
alpines?
A
A
B
Other
thoughts
just
on
the
pro
stuff
like
we
actually
went
through
this
exact
conversation
and
it
was
brandon,
was
there
as
well.
We
were
trying
to
basically
yes
oci,
we're
hoping
we
can
leverage
those
more
and
more
as
pretty
much
every
cloud-native
environment.
Has
you
know
a
registry
and
there's
value
in
building
and
leveraging
that?
But
of
course,
there's
other
there's
existing
packaging
managers
out
there.
So
we
did
do
a
whole
bunch
of
conversations
in
the
pearl
spec.
B
Sorry,
I'm
halfway
pasting,
half
a
sentence
within
the
link
where
we
tried
to
address
that,
because
the
idea
is
that
as
much
as
we'd
love
to
registries
for
newer
things,
there
are
existing
and
pearl
seemed
like
a
good
example.
For
that.
The
the
big
challenge
we
had
with
pearl,
which
I
think
we
landed
on,
was,
is
pearl
a
locate
separating
location
from
identity,
and
I
think
we've
landed
in
a
good
place
through
a
lot
of
long
debate.
B
That
pearl
is
about
identity,
which
has
hints
on
location,
because
the
idea
is
location
is
transient
just
to
solve
that.
So
I
you
know
just
in
this
always
looking
for
other
things,
because
we
originally
in
the
oci
group
couple
years
ago
decided
against
pearl
and
then
I
think
pearl's
evolved
to
help
with
that.
So
it'd
be
great,
for
people
have
some
opinions
on.
A
That
yeah
does
anybody
have
any
thoughts
on
that.
I
know
that's
a
a
pretty
big
topic.
I
I
personally
don't
know
enough
about
either
of
them.
I
mean
I
know,
I
know
what
I
want
to
get
out
of
it.
I
just
don't
know
what
what's
a
best
practice
here
and
and
whatnot.
A
A
Okay,
so
yeah,
my
my
point,
so
just
to
finish
up
quickly
was
was
I
want
to
have
a
way
of
specifying.
A
If
I
did
have,
access
like
you
know,
could
be
a
uri
or
whatever
of
where
would
I
pull
on
that
thing
and
then
other
metadata
that
I
might
care
about,
and
this
is
where
I
think
it
requires
some
flexibility
in
there
and
that's
where
some
stuff,
like
the
package
url
things
seem
to
make
sense
where
I
can
go
and
say:
oh
this
is
this
version
or
whatever?
A
I
know
some
there's
certain
cases
where
you
might
want
to
say
actually
I'm
making
an
attestation
based
on
you
know
a
range
or
whatever
and
then
also
optional,
hashes
and
those
sorts
of
things
that
I
might
be
interested
in,
but
I
think
the
the
big
thing
there
is
is
just
having
some
way
to
easily
describe
that
where
I
know
if
I
have
access
to
it,
where
it
lives
or
not,
necessarily
literally,
where
it
lives,
it
could
be
like
a
package
url
where
it
could
be
a
mirror.
A
You
know
hashes
if
I
need
it,
what
is
the?
What
is
the
type
of
the
thing
which
is,
I
know
a
big
one
right,
which
is
hey
one
of
the
big
ones,
is:
what
is
this
json
that
that
you're
that
you're,
a
testing
like?
Is
it
cyclone
dx
and
json
format?
Is
it
just
some
random
data
that
you're?
I
don't
know
that.
That's
that
sort
of
thing,
I
think,
is,
is
also
another
big
one,
but.
C
I'm
signing
a
a
container
image,
something
like
that,
and
a
lot
of
us
are
very
focused
on
this
thing,
assist
at
this
point
inside
of
an
oci
registry
and
so
we're
we're
kind
of
coming
out
a
little
bit
from
different
sides
and
the
challenge
we'll
run
into
is:
there's
not
going
to
be
like
a
pearl
for
every
different
artifact
type
that
you
can
have
in
a
registry
route.
The
bat
because
there's
already
a
pearl
for
a
helm
chart
so
whether
the
helm
chart
exists
within
a
registry
or
outside
of
registry.
C
A
Oh
one
other
thing
before
I
forget
so
not
next
week
but
the
week
after.
Let
me
just
double
check
here:
yeah,
so
hector
fernandez
will
be
demoing,
he's
been
working
on
actually
using
s-bombs,
creating
a
sort
of
admission
web
hook
that
can
actually
parse
through
s-bombs.
A
So
yeah
we
are
open
to
obviously
thinking
that
that
folks
want
to
focus
on
there's,
definitely
a
few
things
that
that
we
want
to
sort
of
kind
of
talk
through
things
like
you
know,
hey
now
that
we
have
this
data.
What
can
we
do
with
it?
It
might
also
be
valuable
to
kind
of
you
know
talk
through
some
areas
where
hey
when
we
wrote
the
first
draft
of
the
document.
For
example,
some
of
the
spiffy
spire
stuff
wasn't
fully
integrated
in
a
bunch
of
different
pieces.
A
I
know
a
lot
of
work
has
happened
on
that
in
you
know
recently,
where
we
might,
you
know,
be
able
to
kind
of
provide
a
little
more
guidance
around
the
spiffy
spire
stuff,
but
generally,
I
think
we're
open
to
all
sorts
of
new
stuff,
whether
that
is
hey.
We
want
to
focus
a
little
bit
on
writing
some
code
and
writing
some
tooling
around
some
of
these
things
or
what
you
know.
A
What
have
you,
but
I
know
the
big
thing
that
we
just
really
really
want
to
push
out,
is
make
sure
that
this
doc
gets
out
there
so
that
we
can
get
start
getting
feedback
on
it
so
that
hopefully
it'll
be
ready
by
kubecon
valencia.
A
But
yeah
open
to
to
thoughts
and
also
open,
where
I
think,
especially
even
that
it's
the
new
year,
I
know
a
lot
of
folks
have
been
hacking
on
stuff.
You
know
if
december
was
quiet
for
december
was
quiet
for
some
folks.
If
anybody
has
any
sort
of
interesting
things
that
they
want
to
demo
show
off,
discuss
we're
very
much
open
for
the
next,
especially
the
next
few
weeks.
As
far
as
topics
go,
if
I
get
approval,
I
would
very
much
like
to
show
off
some
of
the
supply
chain
querying
stuff.
A
I've
been
trying
to
kind
of
build
out
which
is
like
doing
stuff
like
taking
in
total
attestations
and
following
them
to
the
materials
and
then
making
you
know,
looking
up
that
data
in
stuff,
like
whether
it's
graphics
or
or
document
database
or
recore
or
whatever
or
in
oci,
and
then
continuing
to
kind
of
sort
of
follow
it
down
a
chain.
A
Yeah
yeah,
I
know
it's
it's
it's
like
one
of
the
is
the
big
things
is
like
a
lot
of
folks
are
talking
about.
You
know,
okay
cool.
We
have
some
attestations.
We
can
use
those
attestations
with
web
hooks
and
admission
controllers
like
whether
it's
kiverno
or
or
oppa
gatekeeper
to
sort
of
control
that,
yes,
you
went
through
all
the
right
sort
of
build
processes.
You
have
a
signed
s-bomb.
You
know
whatever
you're
good,
to
go
to
qa
production.
A
That
sort
of
stuff
is
good,
but
then
you
know
what
people
have
sort
of
rightly
pointed
out
that
how
does
that
help
with
the
log
for
j
situation
which
is
sort
of
an
after
the
fact
right?
You
know
it's
not
that
hey.
This
will
help
me
in
the
future
to
make
sure
I
don't
include
a
compromised
or
sorry
vulnerable
version
of
a
log
for
j,
but
that
doesn't
help
me
today
in
figuring
out.
A
What
am
I,
which
of
my
tools,
has
that
unless
I
literally
do
a
scan
against
every
single
s-bomb
that
I
have
so
are
there
ways
that
I
can
start
to?
You
know
build
databases
of
this.
You
know
information
and
so
on
so
that
we
can,
you
know,
run
queries
and
say
hey
whether
it's
like
a
merkle
tree
or
whatever.
Just
like.
I
have
an
artifact
somewhere
in
its
dependency
graph.
Is
there
a
vulnerable
version
of
lava
or
j
right,
just
even
just
starting
there
one
day
we
can
even
kind
of
say.
B
I
mean
that's
kind
of
what
I
was
getting
with
the
s
pump
stuff
is.
Is
it
if
it's
after
the
fact
it's
hard
to
tell
right?
It's
like
dna
analysis
on
soup,
whereas
if
you
know
what,
when
in
it
and
it's
the
log
for
j1,
is
an
interesting
one
as
well
as
some
others
that
you,
if
you
know
what,
when
it
especially
for
compiled
binaries,
then
you
can
use
that
information.
C
C
I'm
basically
just
trying
to
explore
that
a
bit
further.
But
that's
insanity,
a
really
good
tool
to
start
with.
A
A
Yeah
any
other
sort
of
topics
or
or
anything
else
on
that
front.
A
Well,
anybody,
okay,
actually
one
thing
I
would
like
to
ask
just
because
I
know
I've
been
seeing
some
some
stuff
about
some
stuff
that
has
been
has
anything
interesting.
A
Any
new
features
been
released
in
the
past
few
weeks
in
any
of
the
big
pieces
of
software
or
or
any
of
the
sorts
of
you
know
things
that
that
folks
think
is
is
interesting.
I
know
I've
been
seeing
some
stuff
on
the
spiffy
spire
side.
I've
been
seeing
some
stuff
getting
into
I.
I
saw
sort
of
an
open
pr
in
chains
to
kind
of
get
to
kind
of
finish
up
the
spire
integration
curious.
A
If
anybody
is
you
know
familiar
with
any,
you
know
cool,
either
new
tools,
any
sort,
new
features
in
any
existing
tools,
any
sort
of
new
work-
that's
kind
of
happening
outside
of
this
group
that
you
think
is
really
interesting.
C
A
Apparently
I
saw
this,
which
appears
to
be-
I
guess.
Matt
has
a
way
to
sort
of
support,
have
chain
support
ambient.
I
guess
it
just
got
merged.
A
A
All
right
but
yeah,
if
there
there's
nothing
else,
can
the
meeting
up
early
and
we'll
see
y'all
next
week
and
also
you
know
I'll
post
in
the
chat
in
the
next
few
days,
once
we
kind
of
get
that
draft
finished
and
we're
going
to
be
publishing
it
out
and
obviously
the
more
that
the
folks
on
this
call
help
spread.
The
word.