►
From YouTube: ROS 2 Security Working Group (2020-06-23)
Description
Meeting notes: https://wiki.ros.org/ROS2/WorkingGroups/Security
A
B
B
That
reffing
is
doing
most
of
the
reviews
and
I'm
doing
most
of
the
back
fixes,
and
so
I
was
just
trying
to
gather
more
information
both
from
people
who
signed
up
to
be
reviewers
and
active
maintenance
and
from
other
people
from
the
working
group
to
see.
Well,
what
are
the
barriers
or
like
reasons
like?
What
can
we
change
and
improve
to
get
more
active
contribution
and
maintenance
from
the
working
group
and
Esther
student?
B
B
B
A
You
I'm
trying
to
think
how
can
we
get
do
we
have?
Should
we
in
the
in
the
in
the
in
the
for
maybe
in
the
discourse
forum
or
something
or
could
we
have
someone
mention
they
need
a
second
person
and
if
you're
on
the
security
working
group
you
need
to
I'll
say
you
need
to
be
an
active
participant
in
the
reviews.
B
Yeah
I
think
this
is
like
we
establishment
people
like
I,
don't
know
levels
of
involvement
in
the
working
roles-
yeah
rules,
yes,
that
the
word
I
was
looking
for
and
so
and
so
there
is
a
role
of
like
members
which
are
people
like
just
contributing
or
attending
meetings,
without
any
like
responsibilities.
And
then
we
have
reviewers
and
approvers,
and
so
people
released
it
as
reveals
do
commit
to
words.
Repository
and
review
in
a
regular
basis
and
approvals
commit
to
also
do
more,
like
mundane
tasks
of
management,
working
group
and
so.
B
True
indeed,
and
II,
and
so
I
know
like
the
last
three
months,
are
not
very
representative,
because
it's
been
pretty
crazy
for
everyone
for
multiple
reasons.
I
just
wanted
to
know
like
if
there
is
like
anything
from
already
disagree,
viewers
and
then
from
also
be
heard
in
the
working
group
that
could
be
improved
to
like
what
makes
it
hard
to
contribute
or
review
things
in
a
stress
to,
and
it
can
be
documentation.
It
can
be
like
many
things,
I'm
just
open
to
hearing
some
feedback
on
that.
E
So
from
from
my
end,
in
our
end,
I
know
I
know
mikail,
you
requested
help
quite
a
few
times
over
the
past
meetings
and
I'm.
Really
sorry,
I
haven't
volunteered
for
that.
As
you
pointed
out,
it's
been
pretty
hectic
on
our
on
our
end
and
especially
trying
to
get
everything
together.
So
I
don't
know:
what's
the
membership
status
I
have
right
now,
Kyle
I
think
you
assigned
it
at
the
end
right.
D
E
Can
thank
you,
I
can
commit
to
a
higher
level
of
involvement
in
eNOS
was
to
this
is
something
we've
been
pushing
and
pushing
internally
for
quite
a
while.
Frankly
speaking,
I
was
expecting
to
be
fully
involved
into
it
by
now,
but
for
obvious
reasons
we
had
to
kind
of
like
push
a
bit.
Our
roadmap
I
can
tell
you
that
currently,
as
the
outlook
internally
is
that
by
latest
and
but
latest
latest
means
that's
our
hard
deadline.
E
September
I
personally
should
have
bandwidth
to
start
putting
my
personal
time
into
into
adverse
to
contributing
with
more
futures,
reviewing
existing
ones,
triaging
and
so
on
and
so
forth.
So
I'm
expecting
this
to
happen
at
some
point
within
the
summer
and
latest
with
in
September,
might
be
that
something
comes
up
and
I
just
get
bandwidth
starting
from
the
end
of
September.
Something
like
that
from
September
on
I
do
expect
to
put
some
additional
time
hopefully
to
push
in
all
of
these
things.
E
D
D
D
B
B
For
sure,
but
when
I
mean
is
like
as
a
working
group
as
people
like
sitting
on
the
TSC
and
like
we
have
privileged
contact
with
open
robotics,
so
we
I'm
pretty
sure
we
could
have
gathered
more
attention
from
them
as
well.
By
pushing
on
this
end
and
so
I
guess
what
I
wanted
to
know
is
like.
Do
you
want
to
put
a
med
student
with?
B
D
B
A
I
really
like
the
idea
of
adding
it
to
our
are
sort
of
our
agenda
with
where
we
need
help
but
interesting
of
another
project,
I'm
involved
in
we're.
Basically,
they
they
have
a
forum,
and
they
just
asked
for
help
there,
although
it
can
quickly
stop
getting
looked
at.
If
people
don't
want
to
do
it
so
maybe
having
maybe
just
reviewing
them
anything
that
we
need
help
on
every
every
other
week
in
this
meeting
would
be
the
way
to
go
well.
D
B
B
E
I
fully
support
the
idea
that
were
launched
by
maker
of
dedicating
some
time
at
every
one
of
these
meetings
to
review.
What's
the
landscape
of
tickets
within
the
projects
we
are
supporting
within
the
working
group
because
because
otherwise
it
just
gets
complicated
spot
like
like
five
minutes,
where
one
of
you
guys
could
or
or
even
myself,
I,
don't
know.
But
someone
should
just
get
better.
Look
at
that
and
then
just
dedicate
like
a
few
minutes
to
just
go
through
that
and
say
well.
E
B
So
how
do
you
think
we
could
do
that?
For
example,
if
I
put
a
project
board
on
the
Ross
security
repo
organization,
I,
don't
know
whether
it
is
and
we
go
just
through
that
board
on
a
weekly
basis
like
I've
seen
other
do
I
take
the
tooling
working
group
and
then
we
could
just
execute
the
small
amount
of
times
that
we
will
respect.
I
know
for
this
case,
I'm
already
over
by
half
the
time.
So
I
don't
want,
spend
more
time
on
this.
But
I
is
interested
in
having
a
Kanban
board.
B
D
A
A
E
E
Alright,
so
can
you
guys
see
my
screen
right
now?
Yeah
yep,
so
I'll
try
to
be
brief
for
the
sake
of
time,
and
essentially
I'm
gonna
quickly
walk
you
guys,
through
kind
of
like
some
of
the
main
principles
that
motivated
the
design
of
these
database,
which
are
summarized
here
in
introduction.
So
we've
spoken
or
written
about
this
in
the
past,
also
in
some
of
the
discourse
posts.
But
essentially
we
found
that
existing
databases.
The
CVE
list,
for
example,
had
results
which
were
scarce.
E
We
also
when
reviewing
things
noticed
that
many
details
were
missing,
especially
details
that
were
needed
to
reproduce
certain
flaws
because,
as
probably
you
guys
may
agree
with
robotics
as
systems
of
systems
in
many
cases
requires
quite
a
bit
of
detailed
information
or
recipes
to
be
able
to
reproduce
things
appropriately.
So
this
is
one
of
the
things
we
struggled
internally,
quite
a
bit
triage
or
triage.
Wasn't
that
easy?
E
Like
most
of
the
databases
we
found
and
the
discussions
we
had
with
database
owners,
including
the
pool
TV
guys
and
some
others
which
were
private
and
public,
essentially
didn't
encourage
for
public
discussion,
and
we
asked
for
both
assists
and
interacting
with
get
help
or
get
apart
kind
of
like
used
to
that
having
a
ticket
where
you
can
choose
interact
with
your
team
or
with
the
community,
so
that
kind
of
situation
is
something
we
were
aiming
for
missing.
So
it
also
became
one
of
the
principles
we
wanted
to
include.
E
Then
one
of
the
desires
we've
been
having
for
quite
a
while
is
the
assisted
reproduction
of
flaws.
It's
just
not
that
it's
together
to
reproduce
certain
flaws
in
robotics.
It's
also
that
anything
that
can
speed
up
cooperation
in
security
is
essentially
increasing
the
efficiency
of
a
security
team
like
ourselves
as
the
security
working
group
in
Ross.
So
this
also
became
one
of
our
core
goals
and
with
that
we
kind
of
like
started
prototyping
this.
E
This
concept
of
robot
vulnerability,
database
or
rbb
for
short
I
think
I
started
working
on
this
around
2018
late,
2018,
but
I've
putting
time
every
now
and
then
mostly
I,
put
time
last
year
to
push
this
paper
for
a
word
and
also
has
some
baseline
from
where
we
could
build
more
statically,
but
still
there's
lots
of
things
to
do,
and
that's
I
think
why
it's
so
interesting
to
get
this
into.
At
least
these
groups
interest
I
will
skip
most
of
this.
E
E
So
while
we
always
encourage
disclosures,
there
is
a
chance
to
essentially
use
other,
let's
say,
repositories
to
hold
these
tickets,
hopefully
temporarily
at
least
that's
what
we
strive
for
and
currently
I
think
there's
skip
luck,
Waring's
and
there
should
also
be
did
HAP
wirings.
The
taxonomy
is
available.
I
will
not
touch
into
this
right
now.
It's
also
in
the
appendix
in
this
article.
So
you
can
have
a
look
and
send
us
feedback
or
just
open
a
pull
request.
That
would
be
awesome.
E
E
I'd
love
to
you
bypass
this
limitation,
but
the
current
implementation
actually
did
have
just
imposes
this
limitation.
So
currently,
this
is
one
of
the
trade-offs
we
have
to
accept
for
using
it
help
the
user
interface
and
the
review
process
are
very
github,
like
essentially
the
interface
it's
exactly
the
key
from
from
github
and
the
Reaper.
E
E
The
library
itself
is
called,
did
you,
and
essentially
you
just
need
to
train
based
on
a
data
set
and
then
based
on
that
it
does
a
pretty
fine
job
from
time
to
time
it
needs
to
be
retrained,
but
so
far
it
seems
it's
it's
rather
ok,
so
the
article
ends
with
analyzing
the
existing
results
at
the
time,
making
some
plots
and
based
on
these
statistics
arguing
essentially
what's
the
bias.
So
this
data
is
not
updated
anymore.
There's
there's
much
much
more
and
many
many
new
vulnerabilities.
E
So
if
you
guys
are
interested
I
highly
encourage
you
to
go
and
check
RVD
directly,
which
looks
like
this
right
now.
So
there
is
this
R.
It
means
automatically
generated
for
every
action,
that's
being
captured
within
the
CI
system,
which
essentially
is
modifications
in
issues
or
commits
right
now
main
work
can
be
enabled
and
can
be
considered
as
triggers,
but
right
now
those
those
seemed
like
reasonable
for
the
maintenance
we
wanted
to
implement.
These
tables
are
auto-generated
and
it
does
classify
things
based
on
the
component,
robots
and
and
vendors.
E
Of
course,
many
more
classifications
can
be
done.
One
of
the
core
aspects
of
the
database:
it's
that
it's
essentially
classified
and
organized
based
on
tickets,
sorry,
tickets,
labels,
the
main
levels
are
explained
right
over
here:
the
meaning
of
what
an
open
ticket
means,
what
a
closed
one,
the
one
with
the
invalid
label
and
so
on
and
so
forth.
Some
of
them
are
just
self
explanatory,
but
there's
right
now,
like
a
significant
number
of
labels,
last
more
than
250
yeah
268
right
now.
So
quite
quite
a
few
of
them.
A
E
E
We
use
right
now
to
let
me
just
real
quick,
just
try
to
touch
into
that,
so
the
severity
assessment
which
is
I
so
when
you're
asking
this
section.
So
this
is
one
of
the
tickets
out
of
the
mini
mini
available
and
right
now
we're
using
two
separate
the
scoring
mechanisms.
Many
many
more
can
be
added,
but
right
now
we're
using
CBS
s
version
3
and
RV
SS
version
1,
and
each
one
of
the
assessments
is
done
through
the
usual
vector
and
then
the
score
is
typically
auto-generated.
A
So
with
your
so
I
bring
this
up
because
we
have
a
guest
on
the
call
today,
jonno
spring
from
the
software
engineering
Institute
at
Carnegie
Mellon,
who
is
working
on
something
called
SS
VC,
which
sort
of
takes
a
different
approach
than
CBS
s.
Looking
more
at
the
I'll
say,
ask
the
system
owner
as
a
I'll,
say
the
system
owners
impact
rather
than
the
scoring
impact
and
not
kind
of
after
hearing
this
John.
Oh,
is
there
anything
quick?
You
want
to
stay
on
the
SS
BC.
C
Yeah
I
can
but
I
don't
I
mean
I
can
certainly
take
questions
about
it.
I
think
that
it
is
definitely
could
be
really
helpful
here.
We
can
be
a
bit
more
tailored
to
this.
If
I'm
and
I
have
some
feelings
about,
you
know
CBS
s
not
being
suitable
for
something
like
robotics
and
I.
Think
we've
tried
to
address
that
but
Victor.
What
are
you
thinking
so.
E
I
think
you're
right
I
think!
That's
that's
exactly
the
reason
why,
a
couple
of
years
ago,
together
with
a
few
colleagues,
we
started
reviewing
CBS
s
and
came
up
with
these
RVs
s,
which
is
essentially
an
extension
of
CBS
s.
Version
3
towards
considering
the
subtleties
of
robotics
I,
probably
think
we're
gonna
organize
dedicated
speech
on
rvs
s,
so
I
don't
know.
Should
we
push
the
discussion
on
that
for
that
particular
session,
or
shall
we
maybe
just
engage
into
that
right
now?
E
C
E
Right
so
right
now,
currently
most
of
the
tickets
are
populated
by
us.
There
are
some
that
have
been
sent
to
us
privately
and
we
are
still
populating
it
with
the
data
we
receive,
there's
also
the
chance
to
just
populate
it.
Like
yourself,
you
can
create
a
new
issue
right
here
and
there
are
a
few
templates
available,
and
this
template
essentially
recommend
the
right
way
to
fill
it
based
on
the
taxonomy
we
have
defined,
which
is
available
from
from
right
here,
but
as
of
now,
we
definitely
need
more
contributions
from
third
parties.
A
You
also
publish
your
anything
that
comes
to
the
RVD
over
to
like
the
nvd
and
mitre,
because
my
concern
here
is,
as
as
we're
trying
to
get
roz
adoption
in
greater
a
greater
enterprise,
an
IT
space.
You
know
the
companies
are
bringing
up
new
devices,
we
don't
want,
have
to
go
in
and
explain
that.
No,
we
don't
use
CVS,
we
use
our
biddies
right,
so
it's
just
I
want
to
make
sure
they're
represented
in
both
in
both
databases.
So
we
don't
need
to.
E
And
that's
that's
something
I
think
we
discussed
in
the
past.
We
interacted
I,
think
you
yourself
and
I
Joe
in
this
course,
and
and
already
in
the
past,
I
I.
Think
I
did
answer
that,
so
the
the
rationale
for
RVD
is
not
to
duplicate
existing
databases
like
the
nvd.
You
just
mentioned
it,
which
is
a
great
source,
so
we
fetch
data
from
all
those
sources
that
is
robot
or
robot
related.
So
we're
constantly
having
tasks
that
fetches
and
looks
into
those
existing
databases,
and
it
essentially
brings
them
into
our
VD
now.
E
The
reason
why
we
have
our
VD
identifier
is
not
because
we
want
to
duplicate
identifiers
is
because
we
are
required
to
have
them
as
a
CNA.
This
is
a
requirement
that
my
Trey
imposes
on
parties
that
essentially
act
as
a
CNAs
and
we
as
a
CNA
acting
on
some
robotic
components,
need
to
comply
with
it,
but
every
single
one
of
the
tickets
that's
available
within
our
VD.
For
example,
this
one
had
their
own
CBE
ID.
So
this
is
already
the
provided
CVID.
Then
it
also
has
an
ID
which
in
this
case
is
it's.
E
E
Actually,
one
of
the
good
things
about
us
maintaining
this
vulnerability
database
is
that
by
doing
so,
we
are
able
to
track
the
status
of
existing
robot
vulnerabilities
across
different
vendors,
and
we
are
also
able
to
identify
tickets
or
flaws
that
don't
have
cv
IDs
and
we
can
contribute
by
essentially
helping
interact
with
manufacturer
and
assign
cv
IDs
as
appropriate,
so
so
we're
in
constant
cooperation,
actually
with
with
my
tray
and
with
the
whole
I,
would
say,
CNA
structure.
What
does
this
answer?
Your
concern?
It.
A
Sure
does
now:
we
only
have
a
few
seconds
left
before
the
end
of
our
call
that
so
your
answer
was
quite
helpful
there.
So
maybe
we
can
either
continue
this
next
time
or
it
would
be
interesting,
I
shared
in
the
in
the
link
in
the
chat
here,
the
SS
SVC
doc
that
you
may
want
to
take
a
look
at
and
any
other
questions
for
Victor
before
we
Ram
today's
meeting
up.
C
E
Yep
yep,
thank
you
so
much.
You
know
I,
definitely
and
by
the
way,
real
short.
For
the
sake
of
time,
we
definitely
should
follow
up
on
this
discussion
on
scoring
systems.
I
would
love
if
you
can
tag
along
next
telco,
I'm,
very,
very
happy
and
looking
forward
to
get
your
insights
into
how
we
can
get
better
scoring
on
an
overall,
better
prioritization
for
for
robot
floss.
This
is
something
we're
very
concerned
about,
so
so
your
insights
and
expertise
would
be
super
helpful.
B
Victor,
would
you
be
interested
in
having
some
kind
of
like
Q&A
outside
of
this
cool
before
next
time?
We
talk
about
it
just
in
case
like
people
have
questions.
Is
it
possible
to
do
that
over
like
is
a
matrix
or
like
any
asynchronous
place,
where
we
can
just
ask
questions
related
to
this
presentation?
Sure.