►
From YouTube: ROS 2 Security Working Group (2020-10-13)
Description
Meeting notes: https://wiki.ros.org/ROS2/WorkingGroups/Security
B
A
So
you
know
we
can
feel
free
to
add
anything
in
the
only
thing
that
we
had
left
over.
This
is
a
issue
we
started
talking
about
quite
a
while
ago,
and
then
we
resurrected
it
again
last
week,
which
was
the
rcl
issue
545
the
title
of
it
was
move
security-related
system,
filesystem
environment
utilities
outside
rcl.
I
think
it's
evolved
a
little
bit.
Somebody
had
a
chance
to
take
a
look
at
that.
B
I
did
jaime
is
this:
is
this
a
neoprossima.
B
Here-
well,
maybe
not
so
if
I,
if
I
may
give
a
little
bit
of
background
in
case,
people
are
not
up
to
speed
on
this.
The
the
idea
is:
there
are
some
environments
that
don't
have
a
file
system
and
and
roger.
I
actually
seem
to
remember
you
adding
a
little
bit
of
context
to
this
and
saying
that
environment
variables
would
actually
be
off
limits
as
well.
Does
this
ring
any
bells
for
you.
B
B
Well,
so
I
I
did
a
little
bit
of
investigation
into
this
first
of
all,
okay,
so
the
security
implementation
in
rcl
relies
on
the
file
system,
obviously,
because
that's
how
we
find
security
files
and
stuff
and
that's
how
the
security
implementation
works,
but
it's
not
the
only
thing
that
uses
environment
variables,
like
the
rmw
implementation
environment
variable,
for
example,
is,
is
used
there.
B
I
I,
if
we
needed
to
get
rid
of
both
of
those
it
would
have
to
be
you'd,
have
to
specify
those
things
at
compile
time.
I
guess-
and
so
I'm
wondering
so
there-
there
are
two
ways
to
yeah
they're.
B
The
way
to
get
rid
of
environment
variables
is
you'd,
have
to
specify
the
the
armed
of
the
indentation
you're
using
at
build
time
and
then
and
then
we
can
talk
about
how
to
extract
the
security
bits
which
would
get
rid
of
some
more
environment
variables,
as
well
as
the
file
system
bits,
and
there
are
a
couple
of
approaches
we
can
take
there.
We
can
either
remove
it
completely
from
rcl
into
its
own
thing
or
we
can
just
add
a
compile
flag
to
enable
or
disable
it
the
problem.
I
have
with
with
with
both
approaches.
B
Something
we
need
to
consider
is
that
you
know
we
could
like.
Let's
talk
about
a
build
fight,
we
could
say
enable
security
and
we
could
default
to
true,
so
it
doesn't
actually
change
into
this.
The
way
things
are
today,
the
problem
is
that
doesn't
actually
prevent
file
system
stuff
from
leaking
in
later.
B
Because
the
concern
is
not
security
related
the
concern
is
file
system
related.
It
just
so
happens
that
we
use
fastest
some
stuff
in
the
security
bits,
and
so
I'm
having
trouble
coming
up
with
a
design
that
actually
makes
sense
in
a
future
proofing
sense
that
actually
meets
this
goal.
Any
thoughts
on
that.
D
So
so,
currently
we're
tracing
down
the
the
absolute
file
path
and
then
passing
that
to
the
secure
dds
layer
through
the
config
attributes.
D
But
I
think
we,
the
spec,
also
supports,
is
we
can
set.
Instead
of
setting
a
string
to
a
path,
we
can
say
that
the
string
would.
D
Encoding
certificate,
so
it's
thinking
like
if
you're
on
an
embedded
device
or
something
you
would
put
this.
You
know
in
your
in
your
flash
about
like
the
encoding
of
the
pimp
of
the
pim
string
and
then
at
runtime.
You
would
pass
that
as
an
argument.
B
D
D
You
know
searching
of
keystore
unless
you
want
to
have
something
even
more
fancy,
or
maybe
you
have
a
different
encoding
of
a
key
store
like
a
like
a
pem
11
or
something
certificate
blob
that
holds
multiple
keys,
so
yeah,
it's
something
that
needs
to
sort
of
sit
in
front
of
the
side.
Like
you
know
the
abstraction
method.
C
I
didn't
want
to
jump
in
with
one
question
here,
and
maybe
I
missed
it
in
the
earlier
part
of
what
you
were
saying,
but
I
remember
you
know
from
the
comments
that
are
on
there.
You
know
the
original
discussion
in
the
issue
was
to
simply
move
that
functionality
out
of
rcl
itself
into
some
sort
of
separate
library.
C
B
I
think
the
end
goal
is
is
the
same,
and
so
I
I
wasn't
trying
to
actually
come
up
with
the
design.
I
was
it
in
the
I.
The
challenge
I
I'm
trying
to
address
here
is
the
same
challenge,
regardless
of
how
we
decide
to
actually
solve
this
problem,
whether
it's
a
compile
flag
or
whether
it's
extracting
the
security
bits-
and
that
is
this-
the
security
bits
are
not
the
problem.
B
It's
the
fact
that
the
security
bits
happen
to
use
file
systems,
that's
the
problem,
and
so,
while
extracting
security
related
stuff
will
solve
the
problem
now
it
doesn't,
it
doesn't
seem
to
directly
address
this
with
a
design.
You
know
what
I
mean
like
like
at
nowhere
in
rcl.
Do
we
say
let's
not
touch
the
file
system,
you
know
what
I
mean,
and
so,
if
we
extract
security,
whether
that's
with
a
compile
flag
or
or
literally
put
it
in
another
project,.
B
E
Well,
if
I'm
understanding
this
correctly
and
it's
pretty
likely
that
I'm
not
but
it
sounds
like
we
are
dealing
with
a
scenario
where
we
don't
have
a
file
system
and
an
embedded
device.
So,
yes
likely
there
is
no
operating
system
on
this
embedded
device
as
well.
Is
there
any
ways
for
so?
Is
there
any
my
thought
is?
Could
we
just
have
the
build
process
in
one
of
its
directives?
B
If,
if
you
look
at
the
issue,
the
what
he
talks
about
is
cross
compiling,
and
so
I
I
suspect
that,
like
at
build
time,
there's
probably
going
to
be
some
sort
of
file
system,
given
that,
like
it's
pulling
from
the
file
system,
to
build
this
stuff
but
you're
you're
you're,
moving
beyond
my
cross,
compiler
expertise
in
regards
to,
can
it
detect
that
it's
building
for
something
that
doesn't
have.
E
E
Well,
if
we,
if
we're
doing
cross
compiling
it's
been
ages
since
I've
done
not
since
my
intern
days
since
I've
done
that
well
yeah,
I
used
to
work
for
a
company
that
did
some
of
that,
but
anyway,
neither
here
nor
there,
but
no,
I
don't
think
it
would
be
able
to
detect
across
the
wire,
because
usually
what
you're
doing
with
these
embedded
devices
is
you
compile
on
your
system,
then
flash
it
over
to
the
memory,
but
you
could
theoretically
be
able
to
set
some
kind
of
information
about
what
the
target
that
you're
compiling
for
is,
and
you
could
like.
E
B
E
Because
I
don't
yeah,
I
don't
know
that
there's
you
know
now
that
you've
mentioned
cross
compiling.
I
don't
know
that
there's
going
to
be
a
way
for
it
to
auto,
detect
that
build
time,
because
it's
going
to
be
building
on
the
system
that
has
a
file
system
right
exactly
so
we
may,
I
think,
probably
the
best
option
to
future
proof.
This
entire
thing,
because
there's
probably
a
lot
of
other
areas
in
the
code
that
depend
on
file
systems,
not
just
security.
E
E
D
So
so
I
think
the
question
is
we:
we
want
to
expand
the
api
so
that
users
would
have
a
programmatic
method
of
passing
in
maybe
directly
the
the
security
artifacts
they
want.
So
so,
maybe
something
that's
just
an
abstraction
over
the
specifically
rmw
dds
wrappers
like
if
you,
if
you
look
at
how
security
is
used
in
those
yeah,
it's
basically
just
setting
the
conventional
dds
security,
enable
bits
and
then
passing
the
paths
to
those
files.
D
So
we
probably
want
some
kind
of
switch
where
yeah,
depending
on
the
build
flags
we
either
use.
Our
file
system
wrapper
to
implicitly
pull
that
from
the
runtime
environment,
variables
or
picking
up
on
some
expected
struct
values,
or
something
that
the
user
would
set
similar
to
like
how
a
user
can
set
the
quality
of
service
settings.
B
Yeah,
so
there
are,
there
are
two
aspects
to
this
problem
as
as
we're
chatting
about
it,
I
think
we've
broken
it
down.
One
is
how
to
determine
what
capabilities
are
safe
to
use
right,
and
I
think
I
think
I
think
jacob
has
a
good
path
forward
here
with
with
a
build
flag
that
that
I
think
we
can
flesh
out
I'll,
go
I'll
I'll.
Take
an
action
to
go
back
to
this
issue
and
flesh
that
out
a
little
bit
with
with
jacob.
B
Okay,
yeah
I'd
like
to
come
back
to
that
then
and
then
the
other
one
is
given
an
embedded
system
where
we
don't
have
the
file
system.
Is
there
a
way
we
can
actually
still
make
security
work
right
and
that's
the
the
direction
you're
going
now
yeah
ruffin?
B
Okay,
do
we
want
do
we
want
to
revisit
the
the
build
flag?
Real,
quick,
make
sure
we
have
a
good
direction
forward
before
we
switch
to
that.
E
Well,
the
thought
that
I
have
on
the
build
flag
is
that
you're
going
to
be
passing
in
the
build
flag
when
you're
trying
to
build
ross
hunters
on
your
system
and
all
your
packages,
which
means
that
we
are
going
to
be
pushing
off
work
onto
all
the
maintainers
of
packages
to
define
a
whether
or
not
their
package
can
even
be
built
in
embedded
and
b,
to
provide
a
system
of
what
is
not.
What
is
disabled
and
embedded.
B
Mean
compared
to
the
way
it
is
today
right
where
there
is
no
build
flag,
and
so
people
just
kind
of
do
whatever
they
want.
This
doesn't
actually
change
the
status
quo.
It
just
gives
them
the
ability
to
just
say
you
know
what
I
actually
do
want
to
support
this
use
case,
I'll,
detect
it
and
I'll
do
this
specific
thing
they
don't
have
to,
though
right
changes,
nothing.
B
E
E
C
C
Embedded
expert
by
any
means,
but
I
could
certainly
envision
platforms
where
you
could
have
the
same.
You
know,
architecture
that
can
run
the
same
executables
and
some
of
those
you
know
packages
may
have
file
system
stuff.
Some
of
them
may
not.
You
know.
I
don't
know
that
the
system
architecture
is
going
to
prevent
you
from
including
file
system
stuff,
even
if
the
hardware
doesn't
have
it.
B
E
E
Right
personally,
I'm
I'm
sort
of
the
cautious
type.
That's
partially,
why?
I
don't
talk
much
during
these
meetings,
so
I'm
I'm
more
comfortable
with
the
you
have
to
explicitly
opt
in
to
the
embedded,
because,
I
would
say
a
fair
assumption,
maybe
eight
times
out
of
ten
nine
times
out
of
ten
somebody
wants
to
build
something
for
embedded.
They
want
to
build
it
once
and
they
wanted
to
run
and
they
wanted
to
run
for
a
very,
very
long
time
without
any
problems
occurring.
D
E
Sorry,
good,
no,
I
was
just
going
to
say
so.
That's
that's
basically,
my
reasoning
why?
I
would
want
it
to
be
an
opt-in
sort
of
thing,
because
that
way
you
can
guarantee
to
the
person
hey
by
me
implementing
this
this
system
for
embedded.
I
have
already
done
the
work
dotted
the
eyes
crossed
the
t's
and
made
sure
that
this
is
going
to
work
for
embedded.
B
E
No,
it
doesn't
require
them
to
say
they
don't
support
it.
We
just
assume
they
don't
by
default.
D
The
it
seems
like
we
want,
like
a
a
community-wide
kind
of
acknowledged,
build
setting
like
like
in
rust.
You
have
like
no
sdd
so.
D
Yeah,
if
you
support
that,
then
your
package
is
smart
enough
to
you
know,
accept
that
configuration
and
build
artifacts
that
are
support,
running
environments
with
no
standard
library.
So
maybe
maybe
this
is
something
we
could
probably
collab
with,
like
micro
ross
and
by
the
team.
I
expected
that
some
setting
for
that.
B
No,
the
what
we're
talking
about
is
where's
that
link.
B
B
Here,
where
the
request
is
to
to
support
basically
not
relying
on
the
file
system
in
rcl,
which
is
the
the
thing
that's
currently
relying
on,
the
file
system
are
the
security
features,
and
so
we're
talking
about
ways
to
instead
of
just
kicking
the
can
down
the
road
and
trying
to
fix
that
particular
problem.
We're
trying
to
talk
about
ways
to
have
a
build
flag,
that's
available
across
the
projects
that
you're
building,
that
that
says
what
type
of
platform
you're
targeting
whether
that's
linux
or
some
embedded
device
that
doesn't
have
a
file
system.
B
And
then
we
could
take
appropriate
action
and
then
not
only
not
only
us
but
any
other
package.
That
needs
to
do
special
things
for
embedded
devices
as
well,
which.
B
Yeah,
okay,
the
and
I
think
I
think
we
have
arrived
at
a
way
that
allows
projects
to
opt
into
it,
and
so
things
don't
like
it
doesn't
turn
into
an
additional
maintenance
burden.
You
know,
but
it
does
require
everyone
to
kind
of
agree
on
this
build
flag,
so
I
think
it
will
prob.
This
will
probably
turn
into
a
foreign
topic
that
we
can
discuss.
B
Hi
me
I'll,
probably
ping
you
I'll
I'll,
take
I'll.
Take
the
action
of
well.
First
of
all,
I'm
going
to
take
an
action
of
just
talking
talking
on
the
github
issue
there
and
and
making
sure
that
that
would
seem
to
solve
the
issue
and
assuming
it
does
I'll
bring
it
to
the
forum
at
which
point
I'll
ping
you,
jaime
and
and
you
can
bring
the
embedded
working
group
in.
Does
that
sound
good.
F
E
B
B
B
D
D
Some
of
us,
so
I
think,
aside
from
enabling
encryption,
there's
a
part
where
yeah
you
set
the
path
to
the
the
identity
certificate,
the
private
key,
the
signed
permission,
documents
for
the
governance
and
yeah
permissions,
and
so
those
are
the
four
main
kind
of
things
we're
searching
in
the
oh
and
then
the
public
identity,
certificates
of
the
permission,
ca
and
the
gov
and
the
there's
another
ca.
D
Yeah,
so
so
those
are
roughly,
I
think,
the
five
file
paths
that
we
can
all.
Instead
change
from
file
paths
to
perm
strings.
D
F
F
F
In
any
case,
I'm
not
really
sure
about
about
it,
but,
as
I
said
in
any
case,
it
should
be
fairly
easy
because
at
the
end
we
are
just
reading
the
file
content
and
embedding
it
into
into
some
some
parameters.
So
for
us
is
quite
the
same
just
to
to
take
a
string
and
plug
it.
In.
D
Yeah,
I
think
the
the
the
dds
security
spec
kind
of
set
it
so
that
the
argument
api
is,
you
know
the
same,
whether
you're
passing
a
file
of
a
path
of
string
or
a
pin,
encoded
string.
A
A
Yeah,
but
I
mean,
while
we're
at
it,
the
uri
might
be
just
as
useful
that
way
you
could
just
pull
it
dynamically.
F
F
A
problem
in
our
case
so
then
I'm
checking
I'm
checking
the
same
on
the
on
the
counter
and
yeah
we
are.
We
are
not
supporting
it
but
as
we
said,
that
should
be
very
easy
to
implement.
E
Your
system
would
basically
translate
that
to
being
oh,
it
actually
means
xyz
stored
over
a
memory,
address,
6000
and
picks
up
that
memory
and
passes
it
back
to
the
to
the
external.
I
would
imagine
it
would
look
like
they're.
Hopefully
it
would
look
like
they're
accessing
a
file
system,
but
to
the
embedded.
It
would
actually
just
pick
up
the
data
and
pass
it
or
pass
a
pointer
to
the
data.
Well,
no,
you
don't
want
to
pass
a
pointer
to
the
data.
That
would
be
bad.
B
E
You
would
just
so
your
certificates
are
either
going
to
be
your
certificate
files.
Are
they
binary
or
are
they
text.
E
Something
like
that,
if
you
really,
if
you
really
wanted
it
to
you,
could
probably
oh
gosh.
I
hate
to
say
this,
but
because
I
feel
icky,
but
you
could
probably
figure
out
some
way
to
make
it
as
like
a
global
static
variable
that
you
generate
at
the
very
beginning
of
warming
up
ross,
but
that,
like
I
said
that
makes
me
feel
icky.
So
if
somebody
knows
a
way
to
get
get
rid
of
global
statics,
that
would
probably
be.
B
Better,
I
mean
the
only
the
only
way
I
can
see
to
solve
this
in
a
in
a
you
know,
well,
in
a
more
configurable
way
than
having
to
rebuild
the
thing
right
is
to
have
some
external
ca
which
we
sort
of
talked
about
in
the
past
right,
but
we
don't
really
have
that
then
provides
certificates
and
identities,
whether
that's
over
the
network
or
or
over
some
something
other
than
the
file
system
right.
A
D
I
think
we
just
need
a
way
of
similarly
setting
struct
value
values
for
the
security
attributes
and
then
the
user
application
could
do
all
the
logic
on
you
know
where
they
want
to
source
these
security
bits.
Would
it
be
over
some
over
the
wire
or
would
it
be
in
the
flash
or
would
it
be
something
that
you
know
has
an
interface
user
to
the
device
would
put
in
with
a
pin
or
a
tpm
device,
or
something
like
that.
E
If
that
helps
at
all,
so
we
would
need
to
find
some
way
in
order
to
create
the
data
that
could
be
referenced
by
that
variable
and
could
be
passed
from
that
variable
on
command,
whether
that's
at
build
time
or
if
it's
hard
coded
into
the
code
to
begin
with.
Well,
no
that
wouldn't
work,
never
mind
so
yeah,
probably
a
build
or
link.
E
Time
I
think
there
are
ways
that
you
can
has
anybody
else
here,
programmed
embedded.
B
C
D
Sorry
I
worked
at
texas
instruments,
industrial
communication.
She
would
like
using
msp4030s
and
various
spy
idiocy
serial
bridging
interfaces.
E
Okay,
so
please
correct
me:
if
I'm
wrong,
because
I'm
going
out
on
the
limits
of
what
I've
been
able
to
do,
I
did
it
back
in
my
university
days,
although
my
university
is
weird
in
that
you
actually
have
to
work
during
at
the
university.
So
I
actually
did
this
at
my
job,
but
I
think
there
it
might
be
some
way
for
you
to
define
locations
in
yeah.
It's
kettering,
the.
E
I
think
there
might
be
some
way
for
you
to
define
locations
in
memory
where
data
is
stored
and
store
that
data
either
at
the
compile
or
the
link
phase,
because
when
you're
setting
up
an
embedded
computer
when
you're
flashing
it
you
are
centering,
you
are
centering.
You
are
setting
up
the
entire
memory
layout
and
everything
you're
actually
telling
the
memory.
This
area
is
where
my
program
lives.
This
area
is
where
my
data
lives
stuff,
like
that.
B
I
mean
even
that
sounds.
It
sounds
like
it
would
be
doable
to
do
this
at
build
timer.
You
just
essentially
generate
one
big
array.
Yes,
the
the,
and
so
the
challenge
is
not.
How
do
we
accomplish
this
in
a
technical
manner?
It's?
How
do
we
actually
make
that
at
all
user-friendly,
because
the
whole
the
whole
reason
for
structuring
nodes
like
this
and
doing
the
security
work?
D
User,
the
user
would
just
write
some
bit
of
code
that
would
maybe
read
over
a
sd
card
or
spy
interface
or
something
pull
that
memory
into
ram
set
the
attribute
field
and
then
call
the
rest
of
the
stack.
D
You
could
hard
code
it
into
the
binary
executable,
but
I
think
in
practice
you
wouldn't,
because
you
know
you
maybe
built
the
binary
one-
send
over
all
the
devices
right,
just
like
making
sure
that
you
know
users
have
access
to
set
these
security
bits
themselves,
so
they
can
do
it
arbitrarily,
rather
than
having
to
rely
on
some
hidden
logic
that
maybe
make
the
convenience
to
run
it
on
the
desktop.
B
E
E
Yeah
they
have
the
expertise
that
we
need.
We
we
for
the
most
part,
know
what
our
what
our
security
needs
are.
They,
for
the
most
part,
know
how
embedded
works.
So
we
can
just
figure
out
some
way
for
us
to
combine
our
talents
and
figure
out
a
way
that
we
can
build
a
embedded
style,
or
at
least
an
embedded
branch
of
the
code.
E
D
Yeah,
that's
that's
what
I
was
originally
suggesting
to
go.
Talk
to
the
embedded
micro
group.
B
B
E
D
Could
you
could
you
paste
the
exact
time
and
the
matrix
chat
yeah?
That
would
probably
be
good.
B
C
E
B
Okay,
well,
let's:
let's
continue
that
conversation
and
riot
make
sure
that
we're
in
matrix
make
sure
that
that
they
even
have
an
agenda
slot
for
us.
Otherwise,
we
can
set
up
our
own
sort
of
ad
hoc
meeting
with
them.
C
Okay,
yeah,
I'm
guessing
the
ad
hoc
might
be
the
better
way
to
go
about
it,
just
because
we
need
to
pull
in
a
different
group
of
people.
You
know
the
folks
from
here
may
not
be
all
that
involved
in
the
other
topics,
they're
going
to
need
to
discuss
during
their
meeting.
C
B
F
Well,
it's
okay,
but
I
don't
know
if
we
have
enough
time
to
prepare
that
for
tomorrow,
yeah.
B
A
So
I
think
all
that
now
we'll
go
ahead
and
wrap
it
up
not
too
much
other
stuff
I'll,
add
the
action
items
on
there.
If
you
have
any
comments
on
the
action
items,
let
me
know
and
close
out
the
one
for
security
use
cases,
because
I
think
ruffin's
auto
aware
use
case
is
a
good
starting
point
and
roughing
I'm
still
going
to
leave
you
on
the
hook
for
talking
a
little
bit
more
about
that
when
you're
ready.
A
So
unless
anyone
has
anything
else-
and
I
also
encourage
you
to
add
topics
to
the
agenda-
we're
always
kind
of
the
last
minute
looking
to
see
if
there's
anything
to
discuss
and
we
always
get
into
good
good
discussions
during
the
meeting.
So
if
you
have
anything
yeah,
please
drop
it
and
I'll
try
to
troll
matrix
to
make
sure
I
pick
up
anything
that
would
be
worth
discussing
as
well.
A
Anybody
have
anything
else
before
we
close
all
right.
I
think
we're
good
thanks
and
I'll
see.
I
think,
we're
two
weeks
out
for
our
next
meeting.