►
From YouTube: ROS 2 Security Working Group (2020-01-28)
Description
Meeting notes: https://wiki.ros.org/ROS2/WorkingGroups/Security
A
Already,
hey
everyone
welcome
to
January's
meeting
of
the
security
working
group.
The
the
agenda-
and
you
know,
attendance
and
notes-
is
all
in
a
Google
Doc
that
should
be
editable
by
everyone
and
that's
in
the
link
I
just
shared,
so
please
feel
free
to
add
your
name
to
the
attendance
list
and
and
we'll
get
started.
A
A
All
righty,
well
so
something
we've
been
working
on
in
the
working
group.
Most
of
coordinated
through
matrix
is
the
vulnerability
disclosure
policy
that
that
we're
gonna
hand
off
to
open
robotics.
You
know
once
we
once
we
agree
on
a
draft
Sid
you've
been
the
one
championing
that
effort.
You
want
to
talk
about
that.
B
Yeah
sure,
so,
thanks
for
all
the
feedback
and
I
think
we've
got
a
handful
thanks
still
open
issues
you
just
wanted
to
go
over
them
see.
If
you
get
your
feel
for
where
we
stand
on
some
of
the
things
the
actually.
Let
me
share
a
link
to
the
document.
So,
if
you
want
to,
you
can
take
a
look
at
it,
oh
is
that
it
called
it's.
B
All
right,
so
so
just
some
comment
and
going
through
the
comments.
Some
of
the
the
big
issues
I,
think
that
we
as
a
working
group,
have
to
wrestle
through
the
first
one
is
the
scope,
so
what
boner
abilities
actually
do
we
want
to
cover
talked
about
how,
in
a
second
but
so
very
early
on
the
policy
and.
C
B
Is
again
I'm
just
channeling
what
I
see
and
a
lot
of
standard
policies
like
what
we
want
to
solve
here
is:
what's
the
code
that
we
actually
want
to
take
and
own
CVS
or
mol
reports
on,
and
so
initially
I
put
in
the
entire
everything
under
the
github.
That's
kind
of
related
to
Roz
scope
that
back
down
I
think
it
makes
sense
to
call
it
Roz
core
rods
base
and
desktop
and
I
also
scoped
it
for
both
Roz
one
and
Roz.
B
D
I,
just
I
just
wanted
to
share,
maybe
not
on
my
own
words,
but
probably
what
was
shared
before,
which
is
maybe
just
reinforcing
where
people
like
me,
Kyle,
which,
in
my
opinion,
is
somewhat
knowledgeable
about
lost
one
and
and
in
his
suggestion,
essentially
is
to
leave
lost
one
outside
of
the
scope,
so
I
would
I
would
eventually
just
say.
I
would
support
that.
There
are
a
number
of
reasons
behind
that
biggest
one
I
would
say
that,
as
of
now
is
Ross
as
far
as
I
know
only
is
supported
for
genetics.
D
Melodic
has
no
s
Ross
support
at
least
I
wasn't
able
to
launch
and
lots
of
times,
but
probably
will
need
to
make
some
changes
and-
and
we
berate
and
as
far
as
I
know,
it's
not
maintained
anymore.
That's
the
biggest
reason.
Second,
one
may
be
not
interesting,
because
I
think
that's
a
problem
that
in
an
interesting
manner,
canonical
is
solving,
which
is
the
fact
that
there
doesn't
seem
to
be
people
patching
vulnerabilities
and
from
the
last
rows
in
that
conference.
D
We
we
all
got
just
canonical
committed
to
essentially
maintain
rows
one
for
a
number
of
years,
which
I
think
is
super
exciting,
and
it
is
somehow
connected
also
to
the
fact
that
without
s
ross
ross
one
is
just
twenty
I
mean
it's
totally
vulnerable
like
it.
Just
takes
very
little
effort
to
overload
the
processor,
we
have
a
number
of
different
flaws
within
implementation
of
lost
comm
with
of
tcp
and
UDP,
and
no
it's
not
and
other
leaners
containerization
technology
is
helping
me
in
here,
but
but
yeah.
D
My
major
concern
is
is
essentially
that
we
should
focus
as
a
group,
so
I
would
very
much
encourage
ask
to
focus
on
wash
to
also
I
think
that
there's
been
some
great
contributions
from
Kyle
and
some
others
on
the
rush
to
the
know.
Idl
also
look
super
exciting,
though
so
I
would
say
and
I
would
vote.
Let's
go
for
us
two
guys.
A
A
You're
right,
Ross
one
doesn't
have
a
great
security
story,
but
it's
also
what
everyone
is
using
right
now,
right,
I
mean
I
mean
if
you
look
at
the
metrics,
the
percentage
of
people
using
Ross
two
is
really
really
tiny,
and-
and
it's
true,
though,
that's
that's
where
security
is,
is
obviously
important
to
us
right
as
we're
actually
making
it
as
it's
supported.
Your
right
is
more
actively
maintained,
but
but
I'm
concerned
about
coming
out
with
the
vulnerability
disclosure
policy
that
only
covers
things
that
people
are
textual,
accusing.
A
The
coop,
the
obvious
question
after
that,
though,
is
what
happens
when
we
get
one
for
Ross
one.
Well,
there
are.
There
are
numerous
ways
where
it's
insecure,
that
we
can't
fix
right
by
design,
but
maybe
there
are
some
that
that
we
can
fix.
You
know
and
it's
hard
to
know
without
starting
out
with
an
open
policy
and
ratcheting
it
back
as
we
find
things
that
just
don't
work.
A
B
D
A
E
Yeah
I
mean
I,
guess
you
know
from
policy.
You
know
really
doesn't
cost
anything
to
allow
people
to
report
Russ
one
security
issues.
It
doesn't
mean
that
you
know
things
have
to
actually
happen,
so
it
says
well
triage
the
vulnerability
report.
It
may
just
be
that
hey.
This
is
a
known
issue
in
Ross
one.
The
security
story
is
not
great
here
and
you
know
you
may
want
to.
You
may
want
to
find
a
workaround,
but
you
know
we
understand
that
that
vulnerability
exists.
E
I
I
think
it
would
make
sense
since,
since
it
is
like
relatively
cheap
to
just
run
an
inbox
right,
it
did
yeah
it
would,
it
seems
like
it
would
be.
Okay,
I
mean
we're
not
like
offering
bug
bounty.
Is
there
anything
for
for
Ross
one
or
really
committing
to
any
committing
any
resources
to
fixing
problems,
but
like
I'll
set
of
something
big
comes
across,
and
then
it
may
be
something
worth
you
know
actually
looking
into,
but
in
general
I
would
think
that
the
the
scope
of
this
group
is
largely
focused
on
Ross.
A
Yeah
agreed
and
that-
and
that
was
another
thing
that
that
that
we
I
think
probably
want
to
discuss,
there's
a
well
actually
I'll,
come
back
to
that.
Let's,
let's
continue
on
this,
the
is
there
so
your
response
was,
as
was
mine,
Michael,
where,
if
we
end
up
getting
a
report,
that
is
something
that's
by
design
or
something
that
we
can't
feasibly
fix
in
Ross
one
without
breaking
something
I
I
felt.
My
initial
reaction
was
responding
them
saying
we
can't
really
fix
this.
Maybe
you
should
consider
using
Ross
to
write
you.
A
B
I
I
think
it
should
be
rare
that
we
have
a
vulnerability
that
we
can't
least
introduce
some
mitigation
steps
right
and
one
of
them
is
going
to
be
output.
The
robot
on
its
own
separate
network
and
firewall
the
heck
out
of
that
now
and
I
think
that's
going
to
end
up
being
a
standard
solution
for
a
lot
of
things.
B
But
you
know
if
we
find
a
pretty
like
a
straightforward
buffer
overflow
or
you
know
something
that's
actually
easily
contained,
give
it
a
CVE
pageant
and
then
advertise
that
we've
done
that
so
even
if
it's
in
Roslyn,
I,
think
and
I
think
from
Kyle
correct
me
if
I'm
speaking
out
of
turn
here
but
from
canonical
standpoint,
we're
committed
to
doing
that.
You
know
as
part
of
our
support
option,
that
if
somebody
did,
if
a
researcher
says
here's
a
true
flaw
and
here's
the
you
know,
maybe
even
here's
the
code
that's
related
to
that
we'll
patch.
B
F
So
when
one
question
asked
is,
is
how
deep
in
like
the
dependency
stack,
are
we
going
to
try
and
be
responsive
to
so
so?
Maybe
in
that
case
for
Ross
one
and
when
I
was
working
on
s
Ross
one
and
I
had
the
you
know
the
TLS
layer,
the
the
one
aspect
that
was
still
quite
you
know
exploitive
is
if
you
did
get
a
certificate.
F
F
So
I
think
that's
that's
a
relatively
like
low-hanging
fruit,
but
we
have
a
fork
of
a
fork
of
a
fork
of
the
XML
RPC
parser
that
is
sort
of
in
our
code
tree.
So
that's
something!
That's
really
it's
heavily
low-level,
but
we
have,
you
know
that's
sort
of
on
in
terms
of
the
Ross
community.
Yeah
we've
got
about
fixing,
it
was
kind
of
low-level
and
it
sees
well.
A
F
A
So
so
in
in
that
regard,
I
don't
think
that
would
be
covered.
But
that's
not
to
say
that's
not
to
say
that
you
know
in
s
Ross
to
even
or
I
mean
various
parts
of
Ross
parse
XML
or
be
a
mole
or
whatever
right.
How
far
does
that?
Does
that
go
down
to
whether
we're
patching
Yambol
CPP,
all
of
a
sudden
is
that
you
know
is
that
what
you're
really
asking
yeah
I
mean?
A
A
A
A
E
A
E
D
G
The
one
thing
I
was
a
bit
concerned
about
is
like
it
seemed
to
be
under
the
Jeep.
This
working
group
that
was
was
too
focused
and
that
a
lot
of
what
token
robotics
has
been
doing,
but
also
other
people,
has
been
to
not
try
to
improve
us,
one
that
actually
focused
good
practices
on
the
roster
side
and
and
try
to
apply
it
apply
them
to
any
code
that
comes
from
Ross
went
to
us
too,
and
so
there
was
one
of
the
eternities.
G
G
A
Yes,
that's
what
I
want
to
talk
about?
Next,
it's
a
really
good
segue
the
as
we're
writing.
This
is
really
easy
to
assume
that
the
security
working
group
is
the
one
handling
all
of
these,
and
that
wasn't
the
way
that
at
least
we
were
recommending
it
be
set
up,
because
because
that's
that
can
be
some
really
privileged
information
and
I
want
the
membership
of
the
working
group
to
be
a
lot
more
open
than
that.
A
A
So
what
we
recommended
to
open
robotics
was
that
it
be
at
least
to
start
with
someone
from
open,
robotics
and
and
the
chair
of
the
working
group,
which
was
just
Joe
beyond
that,
it's
kind
of
open,
relax,
call
I,
wasn't
going
to
make
one
recommendation
one
way
or
another
if
they
want
to
make
that
a
new
group
or
a
subset
of
this
one.
I
I
have
no
feelings
about
that.
But
this
is
my
concern
about
it.
Being
the
working
group
as
a
whole
makes
sense.
F
B
Is
it
can
we
can
the
working
group
take
on
their
responsible?
Should
we
take
on
the
responsibility
of
doing
the
gun,
the
triage
they
I
keep
that
supper
from
the
actual
fix,
so
that,
like
when
something
comes
in?
Are
we
authorized
to
say
hey?
This
is
a
really
important
thing,
or
this
is
something
that's
not
ours.
So.
A
B
A
B
B
So
so
two
separate
things
so
if
it's
been
disclosed
and
somebody's
got
a
CVA
and
we're
pulling
the
CVE
down,
but
it's
unpatched
right
then
we'll
get
after
that,
and
that's
that's
what
the
the
long-term
support
for
you
know
say:
something's
been
abandoned
and
a
CDs
file,
that's
a
critical
CBE.
You
know!
That's
we'll
get
after
that,
and.
A
A
Right,
well,
it's
it's
to
drive
security
features
in
Ross
too,
and
that-
and
that
brings
us
back
to
the
scope
right.
If,
if
it's
not
the
working
group
which
again
is
focused
on
Ross
to
this
doing,
this
then
does
it
make
more
sense
to
have
this
be
Ross
one
as
well
as
Ross
two
or
should
we
just
start
out
with
it
being
a
smaller
scope
and
and
and
really
it
ends
up
I
think
it
really
ends
up
being
a
parabolic,
Skol
I.
Think.
A
B
B
A
F
F
A
Think
I
would
look
bad
yeah
might
look
bad
if,
if
you
contrast
that
with
how
it
would
look
as
a
so
your
company,
you
are
creating
a
robot
using
probably
Ross
one
right,
just
looking
at
the
percentage
of
people
and
you
find
the
vulnerability
disclosure
policy.
You
know
on
on
an
open,
robotics
web
sites
in
place,
and
it
includes
only
Ross,
not
Ross
one.
Do
you
do
you
take
Ross
as
seriously
as
you
would
if
it
also
included
Ross
one
there's
a
pier
at
these
are
PR
aspect
here
for
that
as
well.
D
Yeah
I
would
agree
with
that
as
well.
I
mean
I,
I,
plus
one.
What
would
make
Island
rocky
next
thing
here
going
though
he
was
two
and
four
was
two,
and
only
was
two
is
likely,
the
best
use
of
our
time.
Frankly
speaking,
I
mean
what
was
one
wasn't
really
originally
created
for
industrial
use
cases.
It
was
meant
for
something,
different
and
and
what's
available
right
now,
which
is
a
great
piece
of
work
for
trying
to
secure
it.
It's
get
a
patch
in
boxes.
D
We
should
really
be
clear
and
honest
about
that,
and
in
Frankie's
can
even
if
we
just
speak,
wash
poor
or
wall
space.
However,
you
want
to
call
it
it.
That's
just
a
small
piece:
I
mean
there's
tons
of
packages
out
there,
which
which
somehow
someone
will
also
me
to
look
at
like
move
it,
for
example,
always
just
hitch
and
and
in
I.
Don't
we
go
or
we
don't
just
just
ensuring
we
we
process.
Somehow
we
did.
D
We
poured
some
on
another
wash
calm,
that's
fine,
but
if
there's
something
that
breaking
I'd
normal
face,
for
example-
and
we
are
asking
for
my
so
so
also
I-
think
it's
kind
of
like
appropriate
for
us
to
push
together
with
certain
robotics
siding
with
regard
aside
that
well,
security
efforts
are
being
concentrating.
Abbas
lets
all
sides,
and
company
is
aiming
for
obtaining
security
which
interconnected
to
safety
and
many
respects.
You
should
totally
start
looking
at.
D
What's
true
and
by
the
way
we
decide
to
mention
tile,
I'd
be
happy
to
argue
on
that,
because
the
ones
I
have
and
I'm.
Currently
looking
at
of
companies
making
use
of
Voss
for
real
industrial
applications,
many
of
them
are
considering
now
to
move
to
Russia
I
mean
there
are
some
big
names
who
already
are
using
was
to
beer
path
and
many
others.
A
F
The
one
aspect
that
they're
just
made
one
aspect
I
think
that
would
be
maybe
beneficial-
is
the
aspects
of
porting
the
packages
so
like.
If
we
do
get,
you
know
maybe
like
a
remote
code,
execution
vulnerability,
maybe
like
one
of
the
higher
level
Ross
one
packages,
that's
being
really
straightforward.
They
ported
to
Ross
to
that
might
be
like
a
nice
helpful
early
canary
in
the
coal
mine
too,
so
that
when
we
do
port
it
to
Ross
to
we
do
it
correct.
So
just
one.
G
Yeah,
that's
another
another
issue
which
is
a
this
trade,
not
not
very
thoughtful
port,
which
happens
quite
a
bit,
but
so
yeah
that
was
never
helped
us
just
I
wanted
to
make.
Will
just
one
quick
remark
on
the
on
the
PR
aspect,
because
I
think
it
can
really
also
go
both
ways
as
a
person
trying
to
exploit
some
deployed
resistant,
getting
a.
We
can
use
data
from
open
robotics
with
the
list
of
exploits
and
attacks
that
I
can
use.
A
G
More,
it's
more
harness,
at
least
to
their
connect,
straightforward
to
say:
hey,
we're,
not
gonna!
Try
to
do
that
in
Reverse!
One
because,
like
we
know
it
was
not
nice
I
mean
referenced
and
I
explained
some
time
and
did
amazing
work
on
like
trying
to
push
like
as
Ross
one
forward
but
like
we
can
of
like
gave
up
on
it
now
and
decided
to
like
try
to
get
in
rows
two
and
so
on.
E
I
was
just
gonna,
say:
I
think
you
could.
You
could
probably
caveat
this
document
somehow
in
such
a
way
that
it's
like,
if,
if
you're
a
user
that
is
interested
in
security
and
safety
more
than
anything
else,
then
we
have
to
recommend
that
you
use
Russ
yeah.
There
was
a
great
point
and
because
of
that,
that's
that's
where
we're
focusing
our
resources
and
energy
in
terms
of
vulnerability
in
bug
reports.
E
A
So
so
are
we
are
we
in
agreement,
then
that
we
should
scope
this
back
to
Ross
and
add
and
add
a
sentence
about
I
essentially,
does
that
I
mean
again?
This
is
all
gonna
go
to
Brian
and
then
Brian
might
say.
You
know
I'd
actually
like
to
include
Ross
one
in
this
and
and
then
that's
fine,
but
but
it's.
B
Okay,
so
I'll
add
something
under
the
scope,
but
you
know
just
to
talk
about
Ross.
That's
the
opening
sentence
there,
but
then
I'll
also
add
the
caveat
in
there
right
under
the
scope
says,
if
you
really
care
about
security,
just
skip
bras
one
guy
Russ,
that
kind
of
where
we
landed
okay.
So
those
issue
number
one.
B
There's
one
other
a
lot
of
discussion
about
time
frame
until
we
fix
things,
I
actually
didn't
put
any
time
frames
in
there.
There
are
some
proposals,
maybe
30
days,
maybe
90
days.
My
reason
for
not
putting
that
in
there
is
because
I
don't
want
to
love
your
requirements
on
ourselves.
It
usually
seem
like
the
offense
of
guys,
the
guys
that
find
the
PACS
put
the
onus
on
the
vendors.
So
that's
why
I
didn't
put
it
in
here?
F
E
So
Pat
release
has
happened
about
on
a
two-month,
and
then
things
happen
in
the
middle
of
that
so
at
least
the
Debian
packages
would
be
available,
probably
within
about
30
days,
but
a
full
like
fat
binary.
If
you
were
talking
about
all
the
platforms
would
probably
be
about
60
days
if
it
was
like
absolute
worst
case,.
A
Is
it
that
said,
I
was
taking
notes,
as
you
were
talking,
so
you
may
have
said
this
I'm
sorry,
but
is
there
I
mean
I
like
I
like
the
idea
of
giving
clarity,
you
know
to
people
reporting,
knowing
that
this
is
generally
what
we
like
to
see
is
there?
Is
there
any
downside
to
doing
that?
I
mean
other
than
it
kind
of
puts
us
on
the
hook.
You
know
so.
B
So
so
we
both
seem
to
get
kind
of
commingled
I,
don't
see
both
I'm
saying
but
yeah
and
that's
where
most
of
the
common
ones,
most
especially
a
lot
of
the
active
projects,
seem
to
just
not
say
anything
and
it's
kind
of
like
as
you
you
disclose
it
to
us.
You'll
of
your
requirements
on
us,
we'll
negotiate
with
you
on
that.
Okay,
so
does
that
help.
D
Was
probably
the
one
that
they
insisted,
I
bid
on
on
setting
up
a
deadline,
and
this
comes
from
from
research
we've
been
doing
internally
areas
with
regard?
What's
the
use
well
most
efficient
policy
to
try
to
ensure
that
mitigations
happen
and
and
our
proposal
of
90
days
actually
came
from
or
kim
inspired
actually
by
google
project
zero?
Maybe
some
of
you
guys
are
aware:
it's
a
pretty
cool
group
of
security,
researchers
and
they're,
finding
real
good
stuff
and
essentially,
actually
recently,
they
introduced
some
changes
based
on
the
input
they
got.
D
D
Typically,
they
facilitate
a
path
that
extends
time,
especially
when
the
criticality
of
the
flaw
is
not
so
relevant,
but
I
mean
one
of
the
things
that
I
really
got
surprised.
The
very
beginning
is
that
sometimes
they
even
push
the
deadlines
shorter,
meaning
that
if
the
criticality
of
this
flaw
is
very
relevant,
like
remote
code
execution,
for
example,
exploiting
a
an
exposed
buffer,
overflow
remotely
I,
don't
know
so
in
that.
In
those
cases
they
push
the
deadline
shorter
and
that's
maybe
something
to
discuss
as
well
in
the
future.
D
But
certainly
I
would
encourage,
from
my
readings,
to
just
set
some
sort
of
like
deadline
so
that
we
give
users
the
intuition.
But
there
is
the
responsiveness
behind
the
security
approach
and
that
we
take
it
very
seriously.
But
that's
just
my
humble
output
out
of
the
ring
size
of
made
so
far
and
what
frankly
seems
like
it
was
working
best
in
other
areas.
D
A
D
This
is
essentially
so
if
there's
attached
before
90
days,
we
coordinated
the
we
coordinated
this
culture
together.
So
if
you
attach
it
in
40
days,
then
in
40
days
we
release
it
publicly
and
we
reward
the
researcher.
If,
if
it
takes
100
days,
then,
if
you
haven't
move
fast
enough,
we
will
disclose
it
after
90
days,
that's
kind
of
like
the
it
is
post.
H
Right
just
to
clarify,
though
Google
project
zero
is
actually
the
mirror
of
what
this
group
does
so
project.
Zero
are
the
researchers
that
are
finding
bugs
and
they're
setting
a
limitation
on
what
they
will
do
right.
So,
for
example,
they
could
work
with.
You
know
Ross,
and
we
would
be
then
subject
to
their
90-day
limitation,
so
I'm
a
little
bit
confused.
H
D
C
C
Want
the
users
at
some
point
to
know
that
there
is
an
active
security
vulnerability
that
hasn't
been
triaged
yet
so
we
need
it's
a
responsible
disclosure
policy
that
you
know
if
we
haven't
reached
it
in
this
time.
You'll
know
that
you
know
after
90
days
or
120
days
or
whatever
the
vulnerabilities
will
be
open
to
the
public,
and
anyone
can
see
them
and
understand
how
to
take
steps
on
there
and
to
mitigate
it,
even
if
we
haven't
done
it
yet.
Well,
it's.
H
C
Either
side
can
like
the
idea
behind
me.
There
was
Netherlands
Bo's.
Your
policy
is
that
you
know
the
to
come
to
an
agreement,
but
generally
it's
a
case
of
like
the
minimum
of
the
two
like
we
want
to
give
a
promise
on
our
part
as
the
maintainer
x',
that,
within
a
certain
amount
of
time,
we
will
let
users
know
of
any
vulnerability.
H
C
Usually,
through
some
specific
wording
in
the
policy,
like
you
know,
you
mentioned
project
zero
project.
Zero
has
a
responsible
disclosure
policy,
as
does
a
zero
day
initiative
like
we
should
probably
model
our
policies
off
of
existing
responsible
disclosure
policies
and
responsible
disclosure
is
generally
on
the
maintainer
x'
and
the
promise
that
they
make
right.
B
Then
one-to-one
challenge-
and
this
may
be
a
little
bit
tangential
to
this
discussion
for
the
one
challenge
off
of
modeling
off
of
closed
source
communities-
is
that
they
can
fix
it
behind
closed
doors
and
and
that's
where
again,
maybe
a
bit
of
a
different
discussion.
But
how
do
we
actually
fix
something
given
that,
as
soon
as
you
publish
the
fix,
even
if
it
hasn't
propagated
all
the
way
through
to
the
binaries
it's
out
there
and
you
get.
E
Yeah
so
like
just
looking,
gitlab
uses
hacker
1
and
basically,
if
no,
neither
party
of
checks
it
automatically
gets
disclosed
in
30
days,
but
either
party
I
guess
has
the
ability
there.
I
guess
did
live
in
that
case
and
had
the
ability
to
override
that
deadline
and
let
it
go
longer
if
they
knew
that
it
was
gonna
take
longer
to
Phenix.
But
you
know
it
does
seem
like
they
have
like
a
mandatory.
It's
going
to
get
disclosed
at
a
certain
point
kind
of
situation,
but
they
call
that
out
their
documentation.
E
H
So
that
I
guess
that
depends
a
little
bit.
I
guess
is
just
speaking
from
past
experience
with
like
kernel
level
disclosures,
it
could
depend
on
the
scale
or
you
know,
kind
of
the
severity
of
the
vulnerability,
but
the
ones
that
are
embargoed
usually
are
distributed
to
I,
guess
a
number
of
organizations.
So
if
we
had
a
case
where
a
number
of
companies
or
organizations
are
using
packaging
ross,
then.
E
Would
think
in
at
least
the
scope
of
like
how
their
us
to
release
process
works.
You'd
want
to
wait
for
at
least
a
sink
right
just
so
that
the
the
patches
would
be
propagated.
All
the
way
out
to
the
binaries
yeah
before
supporting
any
sort
of
announcement.
I
guess
that
it's
sink
and
or
patch
release
right,
depending
on
the.
A
H
Yeah,
so
so
as
soon
as
like,
as
generally
availability
of
the
not
the
source
code,
but
actually
like
pushed
upgrades,
that's
when
you
would
do
the
disclosure,
because
otherwise
that
embargo
doesn't
really
benefit
you
much.
If
you
have
I'm
sorry
I'm
getting
so
much
echo.
It's
like
confusing
me
so
yeah,
if
you,
if
you
disclose
it
when
just
the
sources
that
are
available,
then
you
have
this.
You
know
prolonged
window
before
you
have
the
binaries
available,
because
the
binaries
usually
it'll
go
through.
H
A
A
A
Right
well,
I
mean
let's
keep
going
then,
so
there
are
two
aspects
to
a
vulnerability
disclosure
process
right,
and
one
of
them
is
the
public
facing
document
that
that
we
that
we
show
we
actually
do
handle
vulnerabilities.
We
have
a
process
internally
for
doing
this
right
and
here's
how
you
report
something
the
other.
G
G
Like
don't
match
with
the
weather,
is
on
the
on
the
official
document
from
yours
to
open
a
very
excite,
then
it
would
be
a
discussion,
but
I
think
it
still
has
a
pretty
good
like
public
facing
and
PR
aspect
to
make
commit
for
at
least
bother
is
in
open,
robotics
hands.
Then
the
safety
for
what
goes
under
and
what
happened
in
the
past,
like
fining
masses
and
every
intermediate
implementation.
G
This
can,
for
some
of
them,
take
quite
longer
to
actually
like
get
released
or
get
deployed,
which
is
something
there
is
not
too
much
of
an
issue
right
now
for
us
to,
but
may
end
up
being
in.
The
future
as
rest
would
be
used
on
more
and
more
projects.
And
if
you
single
for
I,
don't
know
a
lunar
rover
or
something
it
may
be
a
bit
harder
scratch
almost
like
this
thing.
So
that's
something
to
keep
in
mind,
but
I
feel
like
the
idea
of
having
the
paper
so.
H
I
agree
with
you
me,
Kyle
and
maybe
I
guess.
On
the
flip
side,
the
whoever's
reporting
would
used
as
a
base
the
this
is,
you
know
as
a
project
how
much
time
we
need
to
turn
this
and
come
to
a
point
where
we
can
release
a
binary,
that
all
users
get
updated
and
hopefully,
then
whoever
is
disclosing
could
use
that
as
a
guideline
or
sort
of
like
a
as
they
start
in
the
negotiation
process.
With.
G
A
H
F
E
Yeah
cuz,
just
just
us
by
itself,
you
know,
like
I,
said
where
worst
case
60
days,
but
if
it
was
something
even
deeper,
you
know
and
like
connect
or
something
like
that.
You
know
that
could
potentially
drag
it
out
longer
so
I
mean
I
would
think
like
ninety
days
would
be
safe,
a
safe
starting
point.
You
know
so.
A
G
And
I
think
if
we're
talking
generalities
that
all
serious
I'm
pretty
sure
there
is
some
convincing
that
can
be
done,
that
we
may
like
shorten
the
time
and
actually
get
a
scene
called
batteries
from
a
better
body
before
then,
if
it's
something
very
serious
I
mean
like
the
case.
Well,
you
would
wait
60
days.
I
would
expect
that,
like
not
the
high-priority
one.
E
Yeah
I
think
that's
it
if
you
know
that's
kind
of
patch
release,
steady-state
right,
but
but
patch
releases
can
slide
earlier
or
later
depending
on
on
how
much
you
know,
content
is
available.
So
if
there
was
like
a
big
bug
or
a
big
show,
stopping
something,
then
you
know
it
makes
sense
to
get
it
into
a
patch
release
earlier,
rather
than
rather
than
later.
But
if
it's
like
cosmetic
bug
fixes,
you
know
we
can
kind
of
wait
for
those
to
accumulate
long
enough,
pin
or
justify
you
know
rolling
up
a
patch
release.
B
Yeh
so
I'm
gonna,
I,
think
I'm
after
or
after
the
discussions,
I
think
I'm
going
back
to
where
you
where
you
started
that
Kyle,
which
is
like
there's
the
internal
and
the
external
for
the
guys
externally
we're
going
to
do
our
best
bet,
but
internally,
how
long
until
we
fix
it.
If
it's
30
days,
the
interesting
thing
is
there
now
then
we're
giving
that
to
all
of
the
Ross
code.
Maintainer
x',
that's
a
requirement
right.
B
So
that's
something
I
think
we
would
bring
up
to
the
TSC
because
isn't
that
you
know
if
we
say
this
code
has
to
be
fixed
and
it's
in
some
module
somewhere
that
we
don't
maintain
now
we're
loving
that
requirement
on
the
rest
of
the
Ross
community
right.
So
it
feels
like
there's
and
that's
why
I
sent
that
that
link
to
I
think
that's
how
Apache
does
it
where
they
have
to
the
public
with
this
is
what
we
commit
to
and
then
to
to
the
committers.
This
is
what
you
have
to
handle.
D
So
maybe
connected
to
that
there
is.
There
is
a
very
interesting
discussion
ongoing
right
now
in
a
new
red
which
is
discussing
Ross
to
quality
levels,
I
think
it
was
initiated
by
William
and
it
may
be.
Some
convincing
argument
would
be
that
theory.
Certain
quality
level
maintainer
should
commit
to
patch
security
reports,
as
indicated
by
the
essentially
security
working
group,
that
that
may
be
an
interesting
way
to
go.
Yeah.
G
G
Even
if
right
now,
I
think
it's
way
too
early
stage
and
very
very
fuzzy
and
like
what
gets
in
and
what
doesn't
like
I
still
haven't
been
able
to
figure
out
what
the
criteria,
but
that
could
be
a
way
to
also
say
okay.
This
is
what
we
consider
Russ
kollross
main
in
two
terms,
and
and
then
anything
in
universe
would
not
get
the
same.
That
treatment.
B
So
I
know
we're
running
long
and
we
haven't
gotten
through
all
of
the
issues.
I
think.
If,
if
I
can,
what
I'll
do
is
I'll
take
the
document
as
we
have
it
right
now,
move
it
to
a
new
document,
try
to
split
it
out
to
make
it
a
little
bit
better
for
us
to
comment
and
collaborate
on
the
document
it
just.
B
So
if
you
can
start
thinking
about
this
and
again,
I'll
put
them
in
the
document
that
we
should
teach
or
kind
of
give
a
template
for
vendors
on
how
to
create
their
own
disclosure
of
all
disclosure
stuff
for
their
robots,
that
we
should
probably
create
a
process
for
how
how
to
actually
handle
code
updates
that
include
sensitive
vulnerabilities.
I
can
mention
about
the
separation.
What
Apache
does
a?
B
A
Regarding
Victor's
comment
about
the
the
rep
that
that
William
started,
I
just
shared
a
link
to
it.
He
actually
asked
us
to
go
through
that
the
last
TSC
meeting
so
definitely
something
worth
looking
at,
and
it
is
very
relevant
to
what
we're
discussing
here.
Regarding
you
know,
putting
requirements
on
other
members
of
the
Ross
community
and
I
have
to
show
that
in
matrix
as
well,
because
Google
Hangouts
is
very
ephemeral.
A
A
A
G
F
D
Thing
before
we
close
I
mean
maybe
I
was
to
be
too
harsh
verbally
on
the
criticisms
about
these
merged
or
or
accepted,
commit
right
away,
but
I'd
like
to
understand
a
bit
more.
What
do
you?
What
do
you
guys
intend
to
mean
by
this
veto?
Keep
everybody
decide,
I,
frankly,
have
to
admit.
I
got
very
scared
about
that.
A
D
A
G
A
G
G
Yes,
I,
don't
know
how
it's
been
going
on.
Your
site
came
to
like
move
this
forward,
but
yeah
like
so
just
the
visual
say
they
so
I
think
the
idea
would
be
that
first.
It
would
be
a
trust
to
and
try
to
like
bring
like
new
contribution
to
us
first,
and
that
would
be
the
base
for
people
to
like
be
part
of
like
the
working
group
on
that
community
and
and
then
as
projects
get
added
like,
and
the
idea
would
be
that
people
would
like
I
guess
interest
as
we
go.
G
I,
don't
know
how
like
behind
it,
but
like
people
would
most
likely
that
most
of
them
start
as
like
the
reviewer
or
like
a
tree.
I,
don't
remember
what
the
blames
all
the
Tigers,
the
South
devil
and
like
as
soon
as
a
contributor
be
like.
Can
next
topic
reviewing
and
etcetera
and
like
kind
of
like
climbed.
A
A
Michael
who
so
so,
eventually
what
we'll
move
to
is
is
accepting.
Well,
we
have
the
the
poll
requests
like
templates
for
it,
but
what
we're
hoping
to
move
to
is
is
an
application
process
to
get
new
projects
underneath
the
working
group
umbrella.
But
we
were
gonna
start
by
asking
to
see
if
we
could
get
s
Ross
to
under
there,
but
I'm
not
quite
sure
who
we
need
to
talk
to
you
to
do
that.
E
Yeah,
I
guess
I,
don't
quite
understand
the
question,
so
is
it
moving
as
for
us
to
essentially
out
of
the
Ross
to
org,
is
there
the
Ross
security
or
yeah
okay,
yeah
I
mean
I
can
bring
it
up?
Obviously
we
just
had
her
Ross
meeting
like
30
minutes
ago,
but
I
can
I
can
bring
it
up
at
the
Ross
meeting
next
week,
I
mean
I.
E
Think
if
that's
what
he'll
intend
to
do
and
and
like
commit
to
that
commit
to
you
know,
organizing
or
maintaining
that
organization
and
everything
I
know
I,
don't
foresee
that
there'd
be
any
issues
with
that
I'm.
Also,
the
like
point
of
contact,
I
guess
from
the
Russ
to
team,
so
I
am
going
to
make
every
effort
to
be
at
these
meetings
from
now
on,
so
we
should
have
somebody
from
the
Ross
team
going
to
every
working
group.
Meeting.
I
think
is
the
intention
at
this
point.
Awesome
yeah
great,
but.
A
G
Part
of
the
questions
not
necessarily
on
either
like
location
of
the
repo
itself.
It
would
be
more
about,
like
the
actual,
like
day-to-day
maintenance
of
the
repo.
The
idea
would
be
to
be
able
to
have
like
the
team
and
github
that
can
be
tagged,
which
is
like
the
security
working
group
like
the
maintainer
office
just
to,
and
also
the
ability
like
right
now,
we'll
be
done
in
a
limbo
like
we
don't.
You
know
who
is
reviewing.
We
don't
really
know
who
ran
CI
and
we
don't
really
know
who
merges
here.
E
No,
no
I
I
mean
I,
think
that's
a
good
idea
and
I
think
there's
already
kind
of
a
like.
Maybe
a
reasonable
framework
for
that
in
the
Ross
tooling
group,
as
well,
because
they've
kind
of
started
doing
that
as
well.
So,
like
I
said
I,
don't
I,
don't
anticipate
it
being
any
sort
of
issue.
I!
Don't
think
anybody
finds
other
folks
trying
to
to
take
on
more
in
terms
of
ownership
and
maintain
ownership.
I.
A
E
E
I
mean
I
think
really.
The
only
thing
is
like
if
you,
if
you
were
to
move
the,
if
you
were
to
move
the
S
Trust
to
repo
without
moving
the
release
repository,
then
you
can
potentially
get
some
like
permissions
mismatches
right
in
that
people
who
are
who
have
Roth
security.
Permissions
may
not
have
Ross
security
release
permissions
or
they
would
have
to
have
Ross
to
GBP
organization
permissions
or
whatever,
but
but
I
can
bring
all
that
up
at
the
meeting.
I
think
I
mean
it's,
it's
not
a
complex
to
move
it.