►
From YouTube: ROS 2 Security Working Group (2020-02-25)
Description
Meeting notes: http://wiki.ros.org/ROS2/WorkingGroups/Security
A
B
Yeah,
alright,
fine,
so
we
talked
about
this
at
the
last
meeting
and
the
the
to
the
state.
What
2004
is
the
quality
categories?
Jazzing
5
is
the
standard
library
both
of
them
impact
the
VDP
stuff
that
we're
doing
the
2000
and
well
yeah,
both
of
them
on
the
scoping
side,
as
well
as
the
2004
on
the
the
deadlines.
So,
if
you
recall
we,
we
said
that
that
we
would
like
the
deadlines.
We
gave
people
to
start
publicly
discussing
what
they
disclosed
those
90
days
and
what
we
used
to
determine
that
was
well.
B
D
B
Us
a
90,
and
so
that
30-day
fix,
though,
isn't
just
isn't
just
us
or
the
vulnerability,
handling
group
or
open
robotics
right.
It
actually
ends
up
going
down
to
the
individual
package
maintainers,
and
so
we
wanted
to
make
sure
that
we,
as
a
working
group,
looked
at
both
of
these
from
a
security
perspective.
Really
everyone's
gonna
turn
the
camera
off.
Okay,
fine,
I'm,
I'm,
not
gonna.
Have
this
video
just
be
me.
B
Anyway,
no
now
can
just
be
Joe
anyway,
so
we
wanted
to
give
that
feedback
in
terms
as
of
a
working
group,
which
is
why
we
started
a
document
to
actually
sort
of
gather
this
feedback
and
and
then
we
can
provide
it
in
one
go,
and
we
wanted
to
do
that.
You
know
today,
maybe
tomorrow,
so
we
wanted
to
take
just
one
more
chance
to
sync
and
make
sure
was
was
up
to
speed
on
this.
B
There
were
I,
think
I.
Think
a
lot
of
us
added
our
feedback
to
this
document
already.
But
one
thing
I
wanted
to
talked
about
in
particular
was:
was
that
deadline
to
fish,
so
so
in
rep,
2004
I
think
they
were
rightfully
choosy
about
what
would
go
into
level
one
and,
as
a
result,
level
two
is
is
full
of
really
useful
stuff.
That
I
think
most
robust
will
probably
use
I.
B
I
think
it
makes
sense
to
to
have
you
know,
vulnerability,
deadlines
and
actually
allow
people
to
report
vulnerabilities
against
at
least
both
level
one
and
two
but
I
wonder
if
we
can
degrade
expectations
a
little
bit
for
level
one.
But
then
that
impacts
the
VDP
as
well,
because
we
said
ninety
days,
but
if
we
give
them
longer
than
30
days
to
fix,
then
we
actually
need
to
push
that
out
a
little
bit.
D
Thought
the
report
card
can
make
sense,
like
you
have
these
orthogonal
axes
of
quality
that
might
not
easily
be
summed
up
into
a
single
score,
so
being
more
precise,
what
are
the
strengths
weaknesses,
a
particular
package,
and
this
maintain
leadership
might
be
helpful
to
express
it
easier.
Although.
B
I
agree,
it
is,
it
is
pretty,
is
not
very
fine-grain
tre,
but
even
even
leaving
it
fine-grained,
there's
nothing
not
clear
how
a
user
actually
consumes
this
and
making
it
even
even
more
granular
will
make
it
even
harder
to
consume
the
quality
level,
at
least
with
just
a
couple
of
levels
you
could.
You
could
feasibly
implement
something
like
you
know
the
vintage
repository
components,
but
if
you
make
it
more
granular
right
that
that
sort
of
possibility
quickly
disappears.
That's
really
my
only
concern
with
that.
Oh.
D
B
E
D
B
E
E
You
know
blue
available
one
and
then
comma
some
something
else
and
rather
than
another,
remember
that
could
be
a
you
know,
small
graph
saying
what's
showing
how
it
performs
in
all
metrics.
Then
maybe
you'll
see
that
at
the
package
as
a
mixer
and
good
colleague,
good
code
quality,
sorry,
it
is
well
tested,
it
does
everything
taking
the
checkbox
but
the
Foundation
mini.
And
then
you
know
that
you
can
actually
rely.
G
F
B
C
C
So
I
just
put
something
in
the
chat,
which
is
a
link
to
a
tables
that
they
made,
which
is
basically
defining
like
saying,
like
I,
think,
let
me
up
there
special
yeah,
so
the
rules
are
like.
Basically,
the
rules
and
the
columns
are
like
what
like
the
different
quality
levels
and
that
they
came
tick,
the
boxes
of
like
what
is
needed
to
be
level
1
level,
2
level,
3
level.
C
And
regarding
like
how
would
people
consume
it
I
think
there
may
be
two
like
it's
good
to
have
the
kids,
because
it
just
gives
you
a
general
idea
of
like
okay.
All
this
stuff
is
like
rock
solid
and
then
you're
like
well
I
heard
that
I,
don't
know
which
them
algorithm
to
use
and
well
I
hope
that
these
two
perform
very
well
and
maybe
you're
still
gonna
try
the
two
but
to
decide
what
goes
in
your
final
product.
C
It
may
not
only
be
performance,
but
also
looking
at
the
document
for
that
specific
package,
and
so
in
that
case,
it's
not
just
gonna
be
looking
at
buckets
like
Matt.
They
say
looking
at
like,
which
is
in
one
dot
X,
but
like
picking
between
package
foo
and
bar
you're
gonna
say:
oh
actually,
foo
is
level
two,
but
has
everything
that
documentation
that
Jeremy
was
saying.
Well,
it's
okay,
so
then
I
can
afford
to
use
it
if
I
I'm,
taking
the
risk,
but
I
have
an
easy
way
to
check
for
that
specific
package.
What
is
missing.
B
D
E
B
Okay,
well,
we've
we've
reached
kind
of
the
I
mean
we
could.
We
could
talk
about
this
for
a
while,
but
I
think
I
think
we
have
a
lot
of
good
feedback
here.
I
think
maybe
a
me
Kyle
you
and
you
and
I
can
go
through
this
and
actually
turn
it
into.
You
know
a
nice
comment
and
then
maybe
ping,
the
room
and
everyone
can
review
on
s'mores.
That's
unreasonable,
yeah.
D
C
We
mentioned
it,
but
I
don't
think
we
actually
like
decided
anything.
Does
anyone
has
an
opinion
and,
like
it's
very
hard
to
know
like
what's
the
scope
of
the
VDP
is
gonna,
be
because
everything
is
moving
like
moving
pieces
run
a
lot
of
reps
and
documents
in
parallel,
but
would
people
be
like
prefer
to
have
like
a
narrow
scope
of
packages
that
have
to
comply
with
the
disclosure
time
and
target
on
your
specific
set
of
packages
that
we
can
extend
all
the
time?
A
For
the
vidi
Italian
to
the
VDP
I,
don't
want,
say
you
know
the
night
being
being
an
open-source
project.
The
90
day
disclosure
was
kind
of
a
best
effort.
We
have
to
be
flexible,
someone
in
our
rules
to
so
I
think
the
tearing
thing
is
just
gonna
over
overly
complicate
it,
but
you
kind
of
try
a
blanket
for
for
most
things.
Well,.
B
B
Do
we
want
to
enforce
a
30-day
deadline
on
all
the
quality
levels
that
we
want
to
scope,
or
or
do
we
want
to
degrade
like
for
level
two
sixty
days,
even
though
we're
still
saying
ninety
days,
which
means
they
might
publicly
disclose
something
before
a
fix
is
shipped?
Is
that
okay,
or
should
we
have
30
days
for
everything
that
we
want
to
support
both
level
one
and
level
two
or
does
that
make
sense?
I
mean.
A
We're
we're
working
in
open
source.
So
how
do
we
unless
we're
willing
to
get
volunteers?
Who
can
understand
the
embargo
at
issue
and
want
to
fix
it
in
that?
In
that
time
period
sometimes
I
mean
there's
gonna,
be
things
that
won't
meet
the
30-day
disclosure
I
rather
than
those
tears
that
almost
just
use
the
CBS
s
scoring
based
on
the
severity
of
the
problem
right,
if
it's
CBS
s
higher
criticals
30
days,
medium
can
be
sixty
and
rather
than
about
an
hour.
Oh
nothing,
interesting
for
the
disclosure
part
of
it,
I
mean
for
the
other.
A
B
A
A
B
B
F
If
I
can
just
throw
one
other
thing
out
there,
just
as
I
think
about
how
we
would
integrate
quality
levels
into
the
security
picture,
we
haven't
talked
much
about
it,
but
we're
looking
at
CIS
standards.
I,
don't
know
if
it
might
be
a
type
of
thing
where
we
could
roll
in
quality
level
to
the
overall
quality
and
set
a
quality
firm
for
a
benchmark.
No,
no,
if
that's
an
apples
and
oranges
type
of
thing,
but
that's
another
way
that
we
could
kind
of
get
quality
into
the
security
picture.
If
you
will.
A
C
Yes,
the
ID
enjoys
that
it's
been
a
bit
tricky
to
know
who
to
tag
on
security,
related
changes
in
Russ
to
repositories.
So
most
of
the
time
it's
just
like
someone
mentioning
is
okay
or
Ruffino
me
and
another
thing
it
would
be
good
to
just
if
anyone
happened
is
if
everyone
agrees
with
it
to
just
like
a
scope
and
robotics
to
have
a
security
working
group
team
in
their
organization
when
they
make
changes
to
the
calls
that
have
like
touch,
security
and,
and
so
I'm
not
sure
I
saw
Victor.
C
B
We
chatted
a
me
Cal
and
I
chatted
a
little
bit
of
this
offline,
but
I
want
to
bring
it
up
here.
I
think
it's
a
great
idea.
We
already
have
the
security
working
group
org
and
teams
within
it,
and
ideally
we
could
just
use
that
the
problem
is
github.
Doesn't
support
mentioning
teams
unless
one
you're,
a
member
of
that
team,
and
to
the
repository
or
project
in
which
you're
mentioning
that
team
is
also
a
member
of
the
same
organization
and
so
even
making
even
making
this
team
on
the
Ross
two
org
that
you
know
here.
B
Let
me
just
just
for
everyone's
cut,
so
we're
all
on
the
same
page
here.
This
is
where
I'm
coming
from
I
think
the
github
'z
implementation
of
teams
is
there's
a
big
shortcoming
there
with
with
this.
But
it
sounds
like
that
and
it
sounds
like
they
haven't
fixed
it
yet.
So
the
only
way
this
would
actually
help
us
visit.
A
repository
are
using
a
group.
Admin
was
the
one
that
mentioned
our
team.
Otherwise
you
have
to
be
on
the
team
to
mention
it
which
sort
of
defeats
the
purpose
of
this
I.
D
B
Yeah,
it
just
sounds:
I
mean
I.
I
would
need
to
play
with
this
and
I
know
that
Michal
said
that
the
admin
thing
does
work,
because
he
can
ping
people
as
an
admin
of
an
org.
He
can
ping
teams
of
you
know
in
which
she's
not
a
member,
but
at
least
according
to
this
question,
which
is
still
open
or
I,
mean
it's
closed,
but
it
hasn't
actually
been
resolved
there.
So
Holman
works
for
gab.
B
B
You're,
probably
right
you're
right,
this
isn't
perfect,
but
it's
better
than
we've
got
today.
So
yeah
I
think
it's
a
good
idea
and
eventually
github
will
fix.
This
sounds
like
they're
working
on
it.
A
Be
cool
that
let's
go
to
the
next
topic?
Yes,.
A
C
A
C
G
Yeah
I
can
I
can
I
was
just
listening.
Thank
you,
Miguel
yeah,
I'm,
just
I
mean
I,
think
there's
a
number
of
things.
We
need
to
treat
in
more
detail,
so
I
just
don't
want
to
disrupt
the
flow,
but
I
certainly
think
that
opportunity,
yeah
I'm,
also
thinking
a
lot
about
how
to
handle
certain
things.
I'm,
hesitant
about
some
aspects
and
specifically
I'm
a
bit
doubtful
about
how
to
handle
VDP
related
aspects
due
to
a
resource
problem.
G
I
mean
it's
not
clear
to
me,
who
is
going
to
be
mitigating
this
flaws
at
the
moment
and
I.
Don't
know
if
you
guys
have
canonical
have
more
information
since
you're
interfacing
directly
with
open
robotics,
but
I
guess
this.
This
bits
would
be
necessary
to
advance
here
and
there,
but
but
but
yeah
I'll
keep
myself
tuned
and
whatever
possible
I'll,
just
throw
some
comments
for.
C
Sure
I
can't
speak.
Let
Karen
like
canonical
people
reply
for
the
mitigation
aspect.
One
of
the
motivation
for
the
system
creation
was
more
for
exist,
kind
of
ongoing
work
about,
like
hey,
we're,
gonna
change,
how
security
look
at
or
DGI
security
integrations
in
a
working
Rus.
So
it
was
more
about
like
feature
development
on
Rus
repositories
and
mitigation,
but
you
make
a
very
good
point.
That
mitigation
is
also
like
an
important
thing
to
assess
and
see
who
should
be
mentioned
on
fixes
and
things.
Okay,.
G
C
So
that
is
trust
who
keeps
working
with
that,
and,
and
so
these
changes
for
examples
are
affect
not
about
mitigating
issues
but
about
implementing
features
so
that
things
keep
working,
and
so
that's
the
kind
of
thing
I
was
referring
to
when,
like
when
people
make
changes
that
in
like
have
an
impact
on
security
that
if
they
want
to
have
feedback
from
the
working
group
on
a
change,
they
can
just
type
mention
one
pose
and
yeah
I
can
send
a
link
or
two
of
peels
that
fit
in
that
category.
Okay,
so.
A
Ya
know:
do
you
think
we'll
have
time
for
the
next
five
minutes
to
go
over
this,
your
next
topic,
or
should
we
postpone
that
till
I'm
meeting
in
two
weeks
and
go
over
the
other
short
short
topics.
C
D
Adding
an
idiot
actions
for
the
concept
of
context,
so
just
restructuring
the
keystore
directory
to
take
an
account
with
the
concept
we're
going
kind
of
tweaking
the
way
that
the
lookup
strategy
is
so
by
default.
It's
relatively
similar
as
it
was,
except
that
the
node
name
itself
is
not
used.
So,
let's
say:
if
you
have
all
these
nodes
in
the
root
namespace,
they
will
look
up
their
key
stored
path
and
the
root
of
the
context.
Folder.
D
We
have
a
couple
of
like
alternatives.
We
kind
of
are
thinking
about
and
like
maybe
in
this
like
launch
infrastructure,
we
would
have
something
like
a
push
Ross
context.
So
it's
immediate
explicit,
but
given
that
a
lot
of
other
things
inherent
like
namespace,
pushing
topics,
action
services
having
the
same
kind
of
paradigm
for
context,
I,
think
kind
of
makes
it
more
medial
to
users
to
understand.
D
Additionally,
if
you
happen
to
rename-
or
if
you
happen
to
change
the
namespace
of
a
node
most
likely,
the
permissions
that
node
requires
will
also
change
given,
like
you
know,
the
private
namespace
of
its
parameter
in
API,
like
it'll,
have
a
deem
angles
to
DDS
that
we're
going
to
have
to
be
changed.
So
it's
more
obvious
to
the
user.
That
then
the
context
path
would
change.
D
You
have
some
concerns
in
terms
of
you
know
how
this
would
play
out
in
terms
of
composable
launch
files
integrating
that
with
containers.
The
idea
of
you
have
a
container
that
runtime
you
can
load
nodes
into
so
specify
in
the
context
of
the
container
and
what
which
one
that
gets
inherited
sort
of
a
migration
strategy
for
rmw
implementations
on
haven't
yet
migrated
to
use
in
contexts.
What
do
they
default
to
basically
getting
the
user
in
the
habit
of
having
to
specify
a
context
if
they
still
want
to
use
one
context
per
process?
D
There's
also,
if
you're
dealing
with
like
multiple
namespaces
per
context
like
different
notes
inside,
what's
the
best
way
to
maybe
surface
that
from
a
maintainer
author
point
of
view
of
like
a
package
that
has
like
a
launch
file
that
would
be
imported.
So
yeah
we're
thinking
about
some
of
those,
the
ideas
and
how
they
may
not
also
integrate
in
terms
of
making
it
easier
to
do
static
analysis
from
IDL
and
tooling.
A
E
G
You
so
so
I'm
by
the
way
sorry
mica
rough
night
I
didn't
have
time
to
review.
This
I
actually
didn't
have
time,
but
anyhow
really
shortly
one
minutes.
So
we
are
preparing
this.
Actually,
it's
my
colleague
and
Vika,
who
should
announce
it
soon
he's
coordinated
everything
this
cybersecurity
for
robotics
workshops
as
part
of
the
European
robotics
forum,
which
is
happening
next
week,
actually
in
the
south
of
Spain.
G
So
there's
any
of
you
who
is
interested
in
participating
or
we
have
actually
I
think
in
the
second
session
still
some
spots,
we
could
probably
maybe
also
fit
a
contribution,
though
it's
it's
very,
very
late,
but
happen
kind
of
like
the
late
minute,
so
so
I'm
sorry,
we
didn't
essentially
come
here
and
offer
it
before
we
ourselves
also
getting
both
very
late,
but
anyhow,
if
anyone
is
interested,
reach
out
happy
to
share
a
few
more
bits
and
if
not
any
help
disseminating.
These
would
be
very
appreciated.
G
I
think
it's
being
shared
in
this
course
and
some
robotics
meaning
lists,
but
other
than
that
it's
gonna
be
essentially
catering.
A
number
of
industry
partners
who
are
interested
in
and
security
I'm
gonna
try
to
record
yeah.
That's
right,
Kyle,
that's
that's!
Actually
one
of
the
collaborators
and
that's
Eric
I
think
and
he
was
he
was
trying
to
disseminate
it,
but
we
were
just
not
quite
ready
on
our
on
our
end.
So
now
we
are
in
as
I
was
saying,
we
will
try
to
get
these
slides
and
the
videos.
G
A
Cool
that
sounds
great
yeah.
Definitely,
if
you
want
to
add
up,
we
already
have
the
links.
Yeah
cool
well,
look
at
it.
This
is
awesome
thanks
for
putting
that
time
meeting
together,
so
everybody
sorry
ran
over
a
little
bit
this
time
we
move
those
other
two
topics
up
to
the
beginning
of
the
next
meeting
and
we'll
share
the
video
and
the
notes
and
everything,
and
thanks
for
getting
on
the
call
everybody
have
a
great
day
thanks.