►
From YouTube: Securing Critical Projects WG (October 22, 2020)
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).
B
B
A
All
right,
I'm
here,
do
you
want
to
give
everyone
a
quick
intro
for
yourself
again
just
to
remember
who
you
are
and
then
you
can
take
it
away.
E
So
if
anyone
wants
to
chime
in
or
ask
a
question
feel
free
to,
I
feel
like
the
cues
work
really
well
or
if
someone
wants
to
just
shout
out
like
a
quick
question
and
I
can
quickly
pause
and
then
and
then
we
can
answer
any
questions
that
need
to
be
answered
and
yeah
I'll
with
that
I'll
go
right
into
it.
D
D
E
Is
my
screen
visible,
yeah,
okay,
okay,
awesome,
all
right
so
with
that
I'll
just
go
right
into
it.
So
again,
I'm
amir
montezeri
here
with
ostiff
open
source
technology
improvement
fund
very
excited
to
talk
to
the
work
group
today
about
what
we
do
and
again
how
we
add
value
to
improving
the
security
of
open
source
software.
E
I'm
going
to
talk
about
some
examples
and
lessons
learned
from
doing
it
for
the
last
five
years
and
again
any
questions
or
talking
points
feel
free
to
chime
chime
in
so
to
go
right
into
it
and
to
talk
about
what
we
do
is
we
facilitate
security
audits
and
related
activities
for
open
source
software?
I've
always
considered
us
kind
of
a
one-stop
shop
where
organizations
or
projects
come
to
us
saying:
hey,
we
need
we
need
good
quality
security
work
and
we
make
that
happen.
E
The
proposed
scope
and
cost
of
the
review,
and,
as
I
mentioned
earlier,
we
manage
the
process
to
completion
start
to
finish
by
solving
problems
unique
to
each
project.
That's
something
we
very
much
see
in
the
space
that
no
two
projects
are
like
and
you
really
need
kind
of
a
unique
tailored
solution
to
address
security
needs,
and
we
also
maintain
dialogue
between
stakeholders
again
throughout
the
process,
moving
the
process
along
and
managing
it
to
completion,
and
we
also
focus
on
improvement,
and
we
have
our
audit
teams
focus
on
improvement.
Kind
of
dispelling
that
that
misconception.
E
E
We
were
able
to
actually
find
a
expert
in
not
only
exposure,
notification,
apps
and
app
development,
but
also
the
exact
using
that
the
framework
that
is
used
for
the
for
these
exposure
notification.
Apps
is
also
well
versed
in
that
as
well,
so
you're
able
to
get
a
much
better
person
doing
the
review
than
just
kind
of
a
generic
team
of
a
generic
audit
team.
E
First,
we
have
because
the
projects
are
much
more
focused
and
better
scoped.
You
kind
of
eliminate
a
lot
of
redundancies
and
unnecessary
review
that
can
really
hike
up
the
cost
of
a
review,
and,
as
I
mentioned
earlier,
we
have
a
bidding
system
and
actually
security
teams
bid
against
each
other
to
help
control
costs
as
well.
E
E
Good
first
example
is
with
unbound
dns,
and
this
project
started
back
in
march
of
2019
when
we
met
with
the
isrg
and,
let's
encrypt
and
through
those
discussions,
talked
about
the
importance
of
unbound
dns
as
an
open
source
dependency
and
the
concern
that
it
has
never
been
professionally
reviewed,
which
is
very
consistent
with
what
we've
seen
in
the
space
and
that
many
many
projects.
I'd
say.
A
vast
majority
of
them
have
not
been
professionally
reviewed
or
reviewed,
with
some
kind
of
from
a
security
perspective.
E
So
by
december
we
had
a
complete
audit
and
results
were
published.
All
of
our
audit
results
are
published
on
our
website
for
everyone
to
review,
and
this
audit
led
to
a
total
of
48
changes
and
unbound
that
either
improved
security
or
fixed
issues
that
could
lead
to
future
problems
and
again
that
focus
on
actually
making
changes
and
making
improvements
to
the
security.
Posture
of
the
project
allows
for
these
audits
to
to
really
make
an
impact
on
the
project
and
the
results
being
improvements
made
to
their
security
to
software
security.
E
I
thought
some
very
good
points
were
made
in
threats,
risks
and
mitigations
in
the
open
source
ecosystem.
It's
a
white
paper
that
is
also
on
the
open,
ssf
website.
Talking
about
what
an
open
source
security
program
might
look
like-
and
I
thought
a
great
point
about
security
audits
was
brought
up
in
that
paper.
Talking
about
how
security
audits
are
particularly
important
because,
with
over
two
million
components,
open
source
components-
very
very
few
of
those-
have
actually
been
reviewed
from
a
security
perspective
from
dedicated
experts
who
can
actually
improve
the
security
of
that
software.
E
Next
point
next
lesson
learned
from
this
was
that
by
being
an
independent
organization
facilitating
the
process,
we
were
able
to
facilitate
discussions
between
the
audit
team
and
the
project.
Maintainers
and,
as
I
mentioned,
they
happened
to
have
close
proximity,
and
this
was
pre-covered,
so
there
was
actually
a
tabletop
session
in
which
they
were
able
to
get
together
and
collaborate
and
discuss,
and
we
found
that
that
led
to
many
more
impactful
bug,
fixes
and
improvements
and
to
allude
to
the
cost
of
this
review.
E
So
another,
a
very
common
misconception
with
security
audits,
is
that
they
have
to
be
these
very
expensive
resource
intensive
endeavors
when
that's
certainly
not
always
the
case,
and
not
with
our
experience
too,
because
when
you
have
a
focused
scope,
you
tend
to
have
less
audit
hours
overall
needed
and
that
leads
to
to
both
a
more
effective
review
and
you're
able
to
to
manage
costs
much
more
effectively.
E
E
And
so
the
second
example
of
work
that
we've
done
with
managing
audits
of
open
source
software
would
be
very
much
more
current
events
related
and
actually
led
to
our
introduction
to
this
work
group
and
and
getting
involved
here
that
started
back
in
january
of
this
year,
when
ostaff
had
established
a
strategic
partnership
with
linux
foundation,
which
was
mostly
driven
by
recognize
the
up
by
recognizing
the
opportunity
to
leverage
linux
foundations,
leadership
in
the
space
and
network
of
open
source
leaders
in
the
space,
with
our
with
our
expertise
and
our
ability
to
coordinate
these
audits
and
the
next
couple
months.
E
E
In
this
particular
case,
we
were
able
to
further
add
value
to
the
review
by
engaging
key
stakeholders
in
linux,
kernel,
development
and
looping
them
into
the
process,
so
that
the
review
could
be
as
valuable
as
it
could.
We
were
able
to
get
some
key
stakeholders
involved
in
that
process,
and
so
taking
us
to
where
we
are
today.
The
security
review
is
complete.
E
E
Organizations
of
all
sizes
can
benefit
to,
but
can
benefit
from
access
to
better
security
resources,
and
it
was
very
interesting
to
see
that
even
an
organization
as
large
as
the
linux
foundation
has
some
of
those
pain
points
that
projects
of
all
sizes
have
and
that
they're
so
dedicated
and
focused
on
their
core
business
that
they
might
not
always
have
the
time
or
really
really
the
time
or
funding
or
ability
to
access,
better
secure
resources
and
that's
how
we're
able
to
add
value
to,
by
kind
of
being
that
one-stop
shop
for
them.
E
Having
an
independent
organization
manage
the
process
can
be
a
big
catalyst,
and
this
case
in
particular,
we
learned
from
those
aforementioned
discussions
and
discussions
even
before
that
that
you
know
this
has
been
top
of
mind
for
some
time,
and
even
you
know
a
number
of
years
where
this
has
been
very
much
top
of
mind
and
the
fact
that
we
were
able
to
come
in
and
manage
the
process
to
completion
was
a
big
help,
and
you
know
now
we
have
the
results
that
we
do.
E
E
And
so
to
wrap
it
up
with
some
further
considerations
again,
based
on
our
experience
managing
these
audits.
For
the
last
five
years,
we
found
very
consistently
that
procuring
high
quality
audit
resources,
while
keeping
costs
in
check,
requires
a
significant
amount
of
scoping
and
coordination,
and
that's
another
way
that
we
are
able
to
add
value
to
this
process
by
doing
that
leg,
work
and
that
scoping
and
coordination
on
behalf
of
projects.
E
Furthermore,
reducing
friction
between
the
audit
process
and
project
stakeholders
leads
to
better
outcomes,
and
this
is
also
one
of
the
ways
that
we
have
been
able
to
add.
A
lot
of
value
to
this
space
and
to
this
process
is
that
another
very
common
conception
with
audits
is
that
they
are
very
much
a
resource
burden
on
the
project
and
and
the
stakeholders
involved,
and
and
that
increased
burden
does
not
make
the
audit
worth
it.
E
You
know
for
more
review
because
we
were
able
to
make
the
process
much
better
and
more
meaningful
and,
furthermore,
publishing
results
means
audit
teams
and
stakeholders
put
their
best
foot
forward,
typically,
a
lot
of
audit
teams,
because
they
work
one-on-one
with
clients
and
and
there's
a
lot
of
complicated
legal
reasons.
Why
a
lot
of
audit
teams
do
not
publish
their
work
and
they're,
not
really
able
to
showcase
their
work,
and
so
by
focusing
on
publishing
and
showing
folks
that
these
results
are
going
to
be
published?
Your
name
will
be
on
this.
E
E
I
included
a
couple
of
screenshots
from
community
bridge
from
the
funding
site
in
which
any
project
or
organization
can
apply
for
security
audit,
and
this
is
nice
because
it's
on
the
community
bridge
platform,
which
is
very
much
focused
on
collaboration
and
transparency
and
so
you're
able
to
see.
You
know
like
in
this
example
here
with
the
linux
kernel,
vulnerability
review
that
that
you're
able
to
see
the
sponsors
who
was
involved.
C
I
tell
you
what
let
me,
let
me
just
jump
jump
off
of
one,
I'm
I'm
hoping.
I
don't
think
this
will
be
a
rough
one,
but
can
you
give
a
specific
example
of
one
of
the
specific
vulnerabilities
you
found,
and
I
guess
I'm
really
looking
for
the
little
s3.
I
I
think
this
group,
it's
not
hard
to
convince
any
of
us,
that
security
audits
are
a
good
thing.
C
I
don't
think
you're
going
to
get
a
lot
of
argument
about
that.
But
I'd
just
like
to
hear
a
tale
of
you
know
one
of
the
vulnerabilities
why
it's
important
and
maybe
I'd
love
to
hear
your
speculation
of
why
they
hadn't
found
it
before,
because
for
some
of
these
they
do
already
care
about
security.
It's
not
a
matter
of
they
didn't
do
anything
so
I'd
be
curious
to
hear,
because
I
think
we
all
need
to
make
pitches
to
respective
organizations
that
yes
doing.
Security
audits
is
a
good
thing.
B
C
B
Sure
sure
I
mean
the
real
core
issue
is
when
you're
talking
about
line
by
line
review
by
an
expert
versus
just
using
scanning
tools,
which
many
people
in
the
community
feel
is
sufficient
security
review,
because
they
don't
understand
the
complexity
of
the
issue.
B
B
Right
right,
but
there
was
a
serious
issue.
It
was.
It
was
the
same
kind
of
problem
where
an
implementation
mistake
led
to
a
serious
problem
that
has
to
be
resolved.
So
I
I
think,
that's
the
key
takeaway
amir.
Do
you
have
more
to
add.
E
Also,
what
comes
to
mind
for
me
would
be
granted
it's
a
couple
of
years
old
now,
but
with
the
open,
vpn
review
and
the
closing
those
vectors
for
denial
of
service
type
attacks
and
how
the
audit
team
was
able
to
find
those
those
vectors
and
close
them.
You
know,
by
working
with
with
the
developers
to
eliminate
those
kinds
of
problems
from
happening
again.
I
don't
remember
the
specific
details
of
that
of
that
cve,
but
I
can
remember
anything
on
that.
B
So
the
openvpn
issue
that
was
found
was
another
again.
It
was
an
implementation
error
that
tooling
was
not
going
to
catch.
It
was
a
remotely
triggered
assert,
so
they
knew
that
this
software
would
assert
if
an
invalid
packet
came
through.
That
was
encrypted
with
the
correct
keys.
However,
they
didn't
assume
that
it
could
be
remotely
triggered
and
for
any
openvpn
server
so
because
our
sponsors
for
that
particular
review
were
vpn
providers
who
are
very
concerned
with
the
security
of
their
servers.
E
Yeah
does
that
answer
your
question,
david,
okay,
cool
yeah
and
and
going
back
to
our
commitment
to
publishing
all
of
our
audit
results
can
be
found
on
our
website
and
those
go
into
great
detail
about
really
what
the
nature
of
the
cves
were
and
and
and
how
they
were
remediated
and-
and
that's
all
that's
all
gone
through
in
big
in
in
great
detail.
C
If
I
can
comment,
it's
not
really
a
question,
I
think
you
did
cover
it,
but
it
may
not
have
come
straight
out
because
these
about
the
public
reports,
I
think
there
is
a
carrot
and
stick
nature
of
these
things.
The
carrot,
of
course,
is
they
want
to
do
a
good
job
because
they
know
it's
going
to
get
published.
They
don't
want
to
look
bad,
but
I
think
there's
a
positive
aspect
of
it.
C
We
hinted,
but
I
don't
think
it
quite
came
out
because
they
often
can't
publish
they
often
can't
show
all
the
good
things
that
they
can
do,
which
is
really
good
advertising
for
them
to
show.
You
know
their
good
work
and
I
know
for
a
lot
of
organizations
they.
The
last
thing
they
want
is
public
report
about
their
mistakes,
for
whatever
reason,
so
I
I
think,
there's
a
positive
aspect,
not
just
a
a
fear
aspect,
reason
to
make
things
public.
B
Yeah,
it
definitely
works
both
ways.
Knowing
that
it's
going
to
be
published
definitely
has
the
oh.
We
got
to
make
this
the
best
we
possibly
can,
but
it's
for
good
and
bad
reasons,
because
it's
very
good
advertising
for
somebody
to
post
something
and
show
results
and
they
get
a
lot
of
private
work
out
of
their
public
works.
So
we
kind
of
have
a
unique
opportunity
there,
because
most
of
their
clients
did
not
allow
them
to
publish
anything.
A
Amir,
I
think
you
first
thank
you
for
the
presentation.
This
was
really
helpful
for
me
to
learn
a
bit
more.
What
I
think
you
touched
on
this
when
you're
answering
the
last
question,
though,
but
one
of
the
things
that
I've
heard
is
is
that
there
we
have
these
audits,
but
then
not
everything
gets
fixed.
So
are
these
companies
like
able
to
do
the
actual
work
too
and
like
is
there
you
know?
A
B
Yeah,
it
has
come
up.
It
actually
depends
on
how
interested
in
security
the
project
is.
We
really
haven't,
ran
across
anyone
who
said
yeah
these
issues
don't
matter
to
us,
we're
not
going
to
fix
it
or
we
don't
have
the
technical
expertise
to
fix
it.
It's
usually
a
matter
of
the
project.
Maintainers
want
their
software
to
be
secure.
They
just
don't
that
there's
skill
gaps
somewhere.
B
B
B
A
B
Yeah
definitely
the
one
thing
that
I
would
be
careful
of
with
that
is
fixing
problems
for
them
in
a
way
that
they
then
can
make
the
same
mistake
again
down
the
road,
because
closing
that
class
of
bug
and
making
sure
it
can't
come
back
after
we
walk
away.
Is
the
one
of
the
key
issues
that
we
try
to
focus
on.
A
And
then
one
other
question
I
had
is
there?
Is
there
like
drama
that
happens
after
you
publish
a
report
to
the
maintainers?
Do
they
is
there
like
a
back
and
forth
where
they,
you
know,
talk
about.
C
C
C
That
I've
been
involved
with
with
austin.
So
so
so
we
there's
lots
of
drama,
but
I
think
the
drama
happens
behind
the
scenes
before.
C
Right
right
now,
if
there's
gonna
be
a
disagreement,
you
know
if
you
know
that,
where
you
know
the
audit
report
says
this
is
a
vulnerability
and
the
developers
say
we
don't
think
so.
Yeah
then
there's
going
to
be
some
drama
afterwards,
but
at
least
there's
an
opportunity
to
have
the
drama
ahead
of
time.
A
E
Yeah
and
part
of
the
value
that
we
add
to
these
reviews
is
that
we
do
kind
of
act
as
the
mediator
ford
for
any
kind
of
dispute,
or
things
like
that
to
just
come
up
with
the
best
solution
that
we
can
for
the
project.
B
One
thing
that
we
ran
into
early
on
that
we
corrected
was
making
sure
that
if
the
project
is
already
using
a
specific
developer
environment
and
specific
security
scanners
and
they're
fuzzing
et
cetera,
et
cetera,
we
don't
want
the
security
team
doing
all
of
those
same
things
and
then
saying
yeah.
We
ran,
you
know
clang
against
your
app
and
it
gave
us
88
warnings
and
we
spent
all
this
time
writing
out
this
report
and
sending
it
to
you
guys
and
then
they
come
back
and
they
go
yeah.
We
use
that
tool
all
the
time.
B
We
know
these
warnings
are
not
issues,
so
that
is
a
huge
amount
of
wasted
hours
which
translates
into
wasted
money
and
we
and
we
try
to
avoid
that
as
much
as
possible.
But
this
the
the
upfront
work
of
scoping
things
properly
and
avoiding
these
redundancies,
and
typically
for
for
me,
because
I
usually
am
the
project
manager
for
these
things,
I
can
do
anywhere
from
30
to
300
engagements
between
myself,
the
reviewers
and
the
the
open
source
project.
B
C
Yeah
derek:
can
you
list
like
one
or
two?
I
know
that
you've
already
mentioned
one.
You
mentioned
just
hey,
we
do
scoping,
but
I
think
actually
that's
something
that
really
doesn't
get
enough
discussion.
Is
you
know
scoping?
Can
you
give
a
like
two,
two,
two
more
examples
of
kind
of
the
common
scoping
problems
and
mistakes
or
things
where
things
could
have
gone
awry.
B
Sure
sure
we
focus
very
hard
on
cost
control
and
quality,
because
those
are
the
two
things
that
really
matter
to
us.
We
don't
want
to
cut
to
the
point
where
somebody
can
come
in
behind
us
and
find
a
bunch
of
issues
by
running
some
security
scanner
or
something
that
we
missed,
because
we
cut
too
far
that
happened
with
openvpn,
where
we
had
a
very
tight
budget.
So
we
did
a
change
audit,
which
was
all
of
the
green
code
that
came
out
between
version
2.3
and
version
2.4.
B
So
we
constrained
the
scope
to
just
that
area
of
code,
which
was
something
like
25
of
the
actual
code
base
and
because
we
did
that
somebody
came
back
after
we
did
the
review
and
did
a
bunch
of
fuzzing
of
older
apis
and
openvpn,
and
then
they
said.
Oh,
we
found
four
medium
issues
that
you
guys
missed.
You
guys
are
terrible,
et
cetera,
et
cetera,
and
I
mean
the
people
in
this
room
probably
know
that's
not
how
security
auditing
works,
but
to
the
public.
B
It
does
not
look
great
to
have
somebody
come
in
behind
you,
because
you
didn't
scope
things
properly
or
because
your
budget
was
too
tight,
et
cetera,
et
cetera.
That
was
definitely
a
pitfall
that
we
avoid
from
now
on.
We
try
to.
We
will
just
hold
up
a
project
now
until
we
get
the
appropriate
funding,
rather
than
narrow
the
scope
that
that
was
definitely
an
early
mistake
that
we
don't
want
to
repeat.
C
B
B
Yeah
and
and
we're
also
more
careful
to
just
disclose
what
the
scope
was
when
we
publish
our
work
now
early
on,
we
didn't
do
that.
Yeah.
A
I
I
had
another
question,
maybe
thought,
and
if
anyone
actually
could
probably
answer
this
is,
is
there
what
something
that
I've
been
thinking
about?
You
know
for
certain
bugs
that
you
find.
Is
there
some
sort
of
classification
of
blast
like
radiate
like
radius,
how
bad
this
bug
could
be?
If
it's
you
know,
if
someone
attacked
it
or
something
or
how
bad
this
issue
could
be
like
I
mean,
I
think,
that's
the
thing
that
would
be
interested
with
these
audits.
A
B
Yes,
there
is
so
there's
two
different
classifications,
there's
one
that's
called
a
cwe
and
that
kind
of
gives
you
the
type
or
group
of
bugs
that
you've
encountered
and
then
there's
the
cve,
which
is
like
this
constantly
evolving.
It's
like
a
constantly
evolving
metric
for
measuring
how
serious
a
bug
is
you
mean
perfect,
but
it
does.
It
does
give
you
some
information,
that's
how
we
classify
what's
a
critical
or
severe
bug
against
what.
A
B
Yeah
they
can
be
estimated
by
the
security
team
and
they
usually
are
for
marketing
reasons,
if
nothing
else
the
companies
like
to
tout
when
they.
Finally,
yes,.
C
You
know
the
cvss
spec
itself
is
published,
so
you
can
attempt
to
follow
it
and
and
do
your
own
estimate,
I
I
will
note,
I
don't
think
I'm
spilling
any
grand
secrets
just
because
cvss
is
public
doesn't
mean
everyone
agrees
on
the
values,
red
hat,
typically
computes,
one
value
and
this
computes
a
different
value.
It's
very
often
not
the
same
value,
and
then
they
have
a
discussion
of.
Why
is
it
that
way
versus
this
way?
And
so
on
so
yeah.
B
B
B
Yeah,
it's
definitely
imperfect
like
when
cisco
has
a
bug,
that's
a
hard-coded
admin
password
that
can
be
accessed
remotely.
How
is
that
not
a
10.
B
Yeah-
and
this
is
actually
the
question
that
we
had
recently-
the
security
teams
have
to
justify
security
ratings
if
they
do
put
them
in
the
paper.
So
they
have
to
be
able
to
say
this
is
serious
because
it
leads
to
x,
y
and
z,.
E
Yeah
and
to
also
if
I
could
chime
in
as
well
when
I
was
talking
about
kind
of
some
of
our
main
metrics
or
or
accomplishments,.
E
Finding
you
know,
200
plus
bugs
over
15
audits-
and
you
know,
over
10
percent
of
them
are
rated
as
critical
when
we
compare
that
to
some
other
programs
like
there
are
some
in
the
eu
that
measured
kind
of
their
large-scale
efforts
to
to
to
improve
open
source
software.
E
You
know
with
millions
of
euros
behind
them
and
you
see
what
their
results
are
and
they're
actually
similar,
if
not
slightly
worse
than
what
we've
been
able
to
produce
with
a
much
smaller
budget,
and
I
think
that
kind
of
that
speaks
to
our
kind
of
our
focus
and
our
methodology
that
you
know
we
are
taking
the
responsibility
for
this
and
and
following
it
through
and
with
the
focus
on
getting
as
deep
as
possible
and
doing
the
best
and
most
complete
security
review.
That
can
be
done.
A
Cool,
that's
all
the
questions
I
had.
We
lost
dan,
so
you
you
all
will
have
to
wait
for
for
more.
On
that
any
any
other
questions
for
amir
david
did
you
you're
gonna,
know
cool
jenny.
I
see
you
on
the
call
I
I
was
gonna
see
if
we
could
talk
about
coming
up
with
some
methodology
for
doing
some
more
assessments
on
critical
packages,
but
I
think
we
can
wait
till
next
time
if
you're,
if
you're
going
to
be
around
in
a
few
weeks,
we
lost
jenny
too.
C
A
C
C
A
You
do
you
want
to
do
it,
I
I
don't
know
if
you
want
more
publicity
around
it
or
if
you're,
if
you
either,
you
would
be
interested
in
writing
an
open
like
a
blog
post
for
this
foundation
and
publishing
it
maybe
on
something
that
is
not
as
controversial
or
I
don't
know.
I
don't
really
care
if
it's
controversial,
but
if
you
want
more
publicity
around
the
around
the
work,
you
could
certainly
draft
up
a
blog
post
and
we
can
get
it
posted
on
the
open,
ssf
blog.
C
Obviously
we
can
talk
about
it
publicly,
but
it
has
some
controversial
statements,
but
the
key
thing-
and
I
I
think
the
key
for
any
of
these
reports
is,
if
you're,
making
a
controversial
claim
back
it
up
with
a
reasonable
argument
and,
although
I,
I
think,
derek
and
emir
and
myself
and
greg
kh
were
all
oh,
but
they
had
an
argument,
and
I
think-
and
I
think
that's
actually
a
a
key
point
for
any
any
audit
report,
even
if
it
makes
a
controversial
statement,
is
give
me
a
reasonable
argument
for
the
statement
that
you're
making.
C
A
Yeah
I
mean
work
on
anything
before
anything's
public,
but
yeah
we
have
the
blog.
Here
I
mean
even
even
a
blog
post
about
what
you
talked
about
today
could
be
interesting.
If
that's
you
know,
if
you'd
like
to
publish
that,
I
don't
think
people
know
all
the
details
about
these
audits,
so
it
could
be
helpful.