►
From YouTube: ROS 2 Security Working Group (08 Mar 2022)
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
Thank
you,
jeremy.
Yes,
so
I
already
know
some
of
you,
but
thank
you
for
introduction
joining
me.
I
don't
need
to
introduce
myself
anymore,
so
I
will
give
you
a
presentation
about
the
nodel
project.
B
Okay,
perfect,
so
no
dl
stands
for
the
node
definition
language
and
I'm
going
to
share
with
you
a
whole
overview
of
the
history
of
this
project.
How
it
came
to
be
it's
been
very
much
part
of
the
security
working
group
work
and
I'll
share,
how
it
works
and
where
it's
being
used
and
what
our
goals
are
to
make
use,
make
the
best
use
of
this
tool
that
we
have
so
first
of
all
I'll
go
into.
What
is
the?
What
is
nodel
I'll
briefly
share
the
history
of
it.
B
How
did
it
come
to
be
so?
What
we
have
today,
as
nodel,
is
the
result
of
thought
process
which
led
to
a
design
document
and
later
a
set
of
packages,
specifically
a
python
library
and
a
command
line,
interface
tool
and
I'll
know
that
some
projects
are
already
used
in
it,
which
we'll
discuss
shortly.
B
It
started
as
an
initiative
of
the
robotics
team
at
canonical.
Originally,
the
purpose
was
to
be
able
to
automate
security
policy
generation
in
a
roster
system,
and
for
this
the
problem
was
that
we
needed
to
be
able
to
export
a
node's
interface
like
actions,
messages,
parameters
and
services
that
they
involve,
and
so
the
problem
was
that
there
is
no
way
to
extract
node
interfaces
statically,
and
that
is
what
nodes
no
dl
comes
to
solve.
So
that
is
the
the
reason
for
node
to
exist,
at
least
originally.
B
So,
where
are
we
interested
in
working
on
this?
Well
because
of
our
focus
on
security
and
its
application
to
security
concerns
us,
but
node
dl
became
much
much
larger
than
this.
Also,
it
enables
lots
of
other
possible
tools,
such
as
graphical
interfaces
that
organize
roster
nodes,
automating
from
documentation
generation,
anything
that
can
benefit
from
having
a
declaration
of
your
systems.
Node
interfaces,
basically.
B
So
what
does
nodea
look
like
in
code
by
the
way
all
items
mentioned
here
are
linked
in
the
last
slide
and
we
will
share
the
slides.
As
always,
at
the
end
of
the
meeting,
there
is
a
design
document
draft
the
ros
to
know
definition,
language.
B
It
is
a
draft,
but
no
dll
has
been
accepted
into
a
rost2
enhancement
proposal
that
is
wrapped
2005.
part
of
the
nodel
repo
are
python
library,
node
python.
This
is
the
implementation
of
the
nodel
api
in
python
in
a
rows
to
command
line
interface
tool.
There
was
two
node
dl,
that
is
the
nodel
command
line
tools
for
us
too.
So
I'll
share
about
some
related
projects
as
well
and
we'll
come
back
to
this
later.
There's
the
rust
to
launch
integration.
B
B
So
these
are
all
very
complimentary
to
the
associate
work
that
this
group
has
worked
on
before.
So
there
was
still
a
security
it
uses
nodel
to
extract
load
interfaces
and
launch
with
security,
enabled
it
adds
two
new
optional
arguments
to
ros
to
launch.
That
is
the
secure
flag.
That's
just
secure
that's
to
enable
security
so
to
launch
ros
nodes
with
encryption.
Enabled
that
is
is
a
key
store
path
is
provided,
it
will
initialize
it
if
necessary
and
new
sets.
Otherwise
it
can
generate
one
on
the
fly
as
an
ephemeral.
B
Key
store
for
this
launch
invocation.
Only
there's
also
the
no
create
keystore
flag
that
tells
it
to
not
attempt
to
create
or
initialize
a
keystore
or
create
an
ephemera
one.
So
sorry,
then,
the
node
dlc
policy,
the
security
policy
generator
like
we
said
this
is
tooling
to
generate
a
ros
to
access
control
policy
and
that's
also
based
on
a
node
description
on
nodel
and,
as
was
too
and
we'll
look
at
examples
of
these
packages
that
use
in
a
minute.
B
B
B
B
As
you
can
see,
the
parameters
topic
services,
the
type
of
each
one
of
these
attributes
and
the
role
that
the
node
has
with
it,
which
is
very
important
when
generating
a
security
policy,
for
example.
So
if
the
role
of
the
node
is
a
publisher
to
this
topic
or
a
client
or
server
to
service,
etc,
this
is
just
a
small
example.
We
didn't
want
to
get
too
big,
but,
as
you
know,
there
are
many
many
more
options.
B
We
have
two
verbs
available
to
use
we'll
follow
an
even
simpler
example
for
of
a
toka
listener
for
this
next
few
slides
to
see
it
at
work,
so
the
first
verb
available
is
show
which
basically
pretty
prints
an
odl
information
for
a
given
executable.
So
that's
a
convenient
command
line
tool
to
explore
to
visualize
the
node
interfaces.
B
The
second
one
is
ros
to
node.
L
validates
the
validate
verb.
When
then,
we
we
have
this
square,
which
basically
checks
nodel.xml
file
against
the
schema
and
attempts
to
parse
it.
That
means
this
feature
is
basically
a
debugger
for
your
node.xml
file.
It's
convenient
because
it
will
make
sure
that
it
is
complying
with
the
requirements
of
nodel
and
you're
good
to
use
it
for
all
your
projects.
B
Okay,
the
roster
launch
security.
Again,
you
might
have
used
this
before.
Hopefully,
this
is
a
little
demo
of
how
the
security
tool
is
working.
B
You
have
available
the
secure
flag
which
enables
srs2
security
and,
as
you
can
see,
we
launch
our
notes
with
a
regular
launch
file,
use
a
secured
flag
and
the
data
is
automatically
encrypted,
so
it
finds
the
keys
for
each
node
being
launched.
That
is
part
of
the
enclave,
and
so
your
nodes
are
locked
securely
and
the
data
is
encrypted.
B
So
now
I
want
to
show
a
quick
demo
of
this
package
at
work,
so
this
video
highlights
sort
of
what's
been
done
so
far,
showcasing
this
this
proof
of
concept
in
this
case
for
the
rost2
launch
security
package.
So
let
me
see
if
I
can
play
this
video
now.
B
Okay,
so
let
me
actually
just
switch
to
sharing
my
yeah
I'll
share.
C
B
B
Okay,
that's
really
nice
music
as
well
all
right!
So
that's
just
the
real
demo!
Basically,
what
I
showed
before
in
my
static,
boring
demo,
that's
one
way
to
showcase
these
kinds
of
projects
that
that
we
have
so
sort
of
as
an
example.
B
Okay,
moving
on,
we
also
have
the
the
package
no
deal
to
policy,
as
I
mentioned
before,
which
here
I
created
also
node,
dl
definition,
a
package
that
not
be
on
the
xml
file
on
the
left.
B
B
Obviously
there
are
other
automatic
permissions
for
each
node,
but
it's
been
sort
of
cuts
and
the
topic
permissions
highlighted
here
for
lack
of
space,
but
basically
the
nodel
description
of
a
node
polish
into
a
topic
and
I'm
not
subscribing
to
it-
is
translated
into
allowing
it's
not
this
policy
that
allows
to
publish
or
subscribe
to
the
topic
for
each
node
as
needed.
B
So
what
is
next
for
nodel?
Our
marginal
goal
is
to
promote
the
use
of
security
within
the
russ
community.
As
always,
specifically,
as
we
mentioned
before,
twist
the
use
of
laws
to
security
and
to
leverage
nodegl
for
automated
security
policy
generation.
B
Some
next
steps
that
we
thought
of
and
propose
are
we
want
to
improve
the
documentation
available
in
odl
in
terms
of
the
design
documents
we're
looking
to
get
the
document
merged
and
after
further
feedback
we've
got
from
the
community,
I'm
also
creating
content
for
promotional
activities,
applying
linters
to
the
package
using
the
amendment
framework,
creating
code
examples
of
the
secure
launch,
and
the
idea
importantly,
is
to
use
these
tools
in
the
reference
implementation.
We
have
been
discussing
with
charming
as
well,
so
we
can
showcase
on
automatically
secure
robots.
B
D
D
There's
a
few
questions
that
I
remember
from
earlier,
and
I'm
kind
of
curious
whether
you
know
answers
are
the
same
now
or
if
there's
been
any
further
thoughts
about
it.
One
thing
that
I'm
wondering
is
you
know
the
the
way
that
this
is
set
up.
I
think
works
very
well
for
reasonably
straightforward,
simple
implementations.
You
know.
Obviously
you
know
the
talker
listeners
like
about
the
most.
B
D
You
can
get
on
something
like
that,
but
I'm
wondering
what
happens
when
you
get
into
something
that's
a
little
bit
more
complex
like,
for
instance.
Maybe
you
have
a
launch
file
that
starts
remapping,
parameter
or
remapping
topics.
You
know
from
one
name
to
another.
Is
this
going
to
be
flexible
enough
to
handle
that
kind
of
situation.
A
Yeah,
so
I
may
be
able
to
to
answer
your
question
what's
interesting
with
the
current
implementation,
or
the
current
integration
with
the
launch
file
system
is
that
all
of
this
happens
after
the
whole
launch
system
mechanism,
meaning
the
launch
system
would
take
care
of
all
the
topic,
remapping
and
etc,
and
then
delivers
the
blueprint
of
your
system
to
the
security
part
of
of
the
system.
A
So
short
answer,
yes,
that
that
does
handle
now
topic
remapping
and
it
it
is
able
to
cope
with
a
fairly
complex
launch
system
or
fairly
complex,
robotic
system.
D
Yeah,
I
think
that'll
be
a
very
interesting
question
too.
You
know
once
we
can
eventually
get
something
landed
towards
the
whole
multi-machine
launching
concept
where
you
have
processes
running
on
different
machines
which
might
make
having
the
you
know
single
launch
file
difficult
to
implement
in
practice,
but
I
think
that's
a
that
is
a
down
the
road
decision.
D
One
other
thing
I
was
kind
of
curious
about
so
my
recollection
is
that
this
ends
up
really
kind
of
relying
on
all
of
the
different
nodes
that
you
have
having
the
no
dl
description
underlying
them,
and
sometimes
the
system
is
going
to
include
third-party
nodes
that
maybe
you
don't
have
direct
control
over.
You
can't
go
at
it.
If
the
maintainer
hasn't
put
that
in
there
themselves,
is
there
a
way
to
define
no
dl
for
a
node
outside
of
that
node
itself?
A
Nominatively
by
by
their
name-
and
you
specify
also
the
exact
table,
so
I
I
believe
this
node
xml
file
can
live
outside
of
the
packages
it
actually
defines.
But
I
I
have
not
tried
that
myself
so.
B
D
Okay,
that
sounds
good
see.
It
was
a
was
the
last
thing
I
was
gonna.
Ask
oh
yeah,
I'm
wondering:
has
there
been
any
thought
given
to
trying
to
set
up
something
where
you
could
perhaps
like
introspect
a
running
system
to
help
with
defining
these
no
dl
files?
If
you
do
have
something
that's
large
and
complex,
it
might
be
nice
to
have
a
way
to
just
say:
hey,
go
see,
what's
actually
out
there
running
right
now
and
give
me
something
to
start
from.
A
A
There
are
no
guarantees
that
that
whatever
live
system
you're
using
to
monitor
your
current
raw
system
is,
is
actually
mapping
the
entirety
of
your
ros
graph,
and
that's
that's
how
noble
born
essentially
so
the
idea
that,
by
pushing
it
to
the
the
ros
design
document
and
by
pushing
it
to
the
very
core
packages
of
ros
2,
the
community
would
start
actually
using
it
and
implement
nodel
for
each
and
every
packages
that
that
that
they
provide
to
the
community.
A
We
expect
node
yell
to
to
follow
along,
and
that's
that's
actually
why
we
have
opted
for
using
xml
so
that
it
feels
familiar
just
like
the
regular
package.xml
file
that
that
was
developer
are
used
to
so
no,
there
are
no
tools
that
exist
to
get
you
started,
but
the
idea
that
you
wouldn't
need
one,
because
this
very
large
and
complex
system
would
actually
be
broken
down
at
the
very
node
level
by
each
and
every
developer
of
the
respective
nodes,
and
that
would
essentially
become
a
community
effort
right
so
that
that
also
links
to
your
previous
question
about
using
third-party
nodes
once
that
becomes
mainstream.
A
A
D
C
Actually,
I
have
a
question,
so
one
of
the
problem
that
I
see
here
is
the
correctness
of
the
policy
that
has
been
written
by
the
developer.
So
florencia
said
that
you
are
not
encapsulating
any
static
or
dynamic
analysis
for
the
generation
of
the
profiles,
but
neither
for
the
verifications.
B
C
B
The
time
the
way
it
works
is
the
developer
has
to
develop
this
and
maintain
this
declaration
of
the
notes
interfaces.
B
Precisely
that's
the
problem
that
this
project
is
supposed
to
solve
is
that
there's
no
static
way
to
extract
all
this
information
automatically
from
the
nodes
and
in
the
same
way,
no
way
to
validate
it
so
yeah
that
part
is
the
developer's
responsibility,
they're,
not
term.
If
you
have
anything
complementary
flag.
A
No,
that's
essentially
what
you
said:
there
are
no
proper
static
introspection
in
c
plus
plus
right,
so
there
are
no
ways
to
effectively
extract
all
of
this
information
from
a
c
plus
plus
code
base,
which
is
for
the
better
or
worse,
the
the
very
majority
of
the
roster
source
code
and
and
nodel
tries
to
compensate
for
for
this.
A
E
Sorry,
sorry,
I
joined
late
yeah.
I
had
a
personal
thing
today,
but
just
to
try
to
catch
up
with
the
discussion.
Yeah
look
at
you
so
so
did
you
ask
about
static
analysis
and
and
and
francia
and
jeremy
were
commenting
on
that.
E
I
just
wanted
to
quickly
hint
about
the
fact
that
there's
there's
prior
work
about
static
and
dynamic
analysis
in
ross
2
and
I'm
happy
to
point
out
towards
both
literature
and
actual
source
code
that
does
that
there's
there's
extensive
work
that
was
done
by
myself
and
some
other
colleagues
on
enabling
proper
static
and
dynamic
analysis
on
on
ross2c
plus
class
code
basis.
So
that
is,
that
is
something
very
visible.
You
just
wanted
to
add
that
bit.
I
don't
know
if
that
helps
the
discussion
or
again
I
just
joined
late.
So
sorry.
B
Yeah
hi
pizza,
no,
no
problem.
So
at
the
beginning
of
the
meeting
I
gave
a
presentation
about
nodel,
which
is
a
package
designed
to
define
the
node
ros.
Node
interfaces
select
the
parameters
fixed
action
services
that
they
use
and
know
the
uses
that
this
has,
and
so
we
were
discussing
that.
The
purpose
of
this
package
is
to
provide
this
us
yeah.
Currently,
there's
no
automatic
way
to
generate
these
sort
of
files,
so
they're
manually
created
and
they
can
be
used
for
a
number
of
applications
that
required
node
interfaces
such
as
security
policy
generation.
B
That
kind
of
thing,
but
you
mentioned
static
and
dynamic
analysis.
I'm
not
sure
if
we're
talking
about
the
same
thing.
A
If
I
may
clarify
just
the
semantic,
we
are
talking
about
static
introspection
as
in
static
reflection,
right
analyzing,
your
rost
to
interface
at
compile
time
or
whatever
so
mapping
all
of
the
topics,
services
parameters
that
the
given
node
may
provide.
So
we're
not
talking
about
code,
static
code,
analysis.
B
E
It
yeah
well
awesome.
Thank
you
guys,
so
I
think
so.
I
didn't
know
that
no
dl
was
and
again
I
I
didn't
know
that
no
deal
I
mean
I,
I
have
read
the
source
code
at
least
last
time
I
checked.
I
knew
it
was
declarative,
as
I
think
jeremy
you
just
pointed
out,
but
if
you
guys
have
extended
it
for
having
capabilities
to
introspect
the
computational
graph
from
the
source
code.
That
is
fantastic.
If
not
there's
some
some
interesting
work
from
some
other
community
members.
E
We
could
leverage
if
that's
something
desired,
but.
A
E
Yes,
so
yeah,
would
you
like
to
go
first?
If
not,
I
can
give
a
pointer
to
the
github
repo,
where
this
is
leaving.
C
If
you
can
do
so,
I
will
more
than
welcome
since
I
am
from
my
phone
now
sorry
for
the
question.
So
thanks.
E
Yeah,
no,
no
problem,
so
the
I
can
share
my
screen
or
just
paste
it
in
the
chat
in
here.
So
this
is
the
project
that
comes
to
mind,
guys
for
what
concerns
static
introspection
of
the
computational
graph,
and
I
I
can't
comment
on
what
concerns
support
for
ros
2.
But
last
time
I
checked
for
was
one.
E
It
was
doing
a
fantastic
work
for
introspecting,
the
computational
graphs
directly
from
the
source
code
and
what
it's
essentially
doing
is
indeed
static
analysis,
just
not
for
the
sake
of
doing
security
assessments,
but
for
the
sake
of
doing
quality
assurance
and
and
yeah
it
does
build.
One
of
the
sub
modules
of
harass
is
actually
focusing
on
building
this
essentially
graphs
or
compositions
out
of
the
source
code.
E
So
that
is
absolutely,
I
think,
something
pretty
handy
for
you
guys
working
in
in
odl
it
matches
quite
nicely
again.
I
can
comment
on
the
roster
status
of
the
source
code,
but
I
I
do
know
the
maintainer,
and
probably
many
of
you
know
him
as
well
andre
and
he's
he's
a
very
approachable
guy
and
he
might
be
willing
to
help
with
this.
E
Yeah
I
mean
at
the
end
of
the
day
I
think
the
the
logic
to
generate
this,
like
kind
of
like
statically,
inferred,
crafts
from
the
source
code.
It's
a
bunch
of
python
scripts.
So
I
don't
think
that
the
changes
would
be
like
substantial,
but
but
yeah
that's
something
maybe
andre
can
can.
Maybe
we
can
invite
him
jeremy
to
the
next
call,
and
maybe
he
can
enlighten
us
with
his
views.
C
And
another
thing
that
I
was
thinking
about
when
we
discussed
about
the
policy
generated
by
nodial
I've
been
concerned
a
bit
about
the
minimality
of
what
is
generated.
So
if
we
had
a
way
to
verify
that
the
policy
process
generated
is
indeed
the
most
fitting
one,
that
would
be
awesome
at
this
stage.
I
don't
think
that
is
something
available
right.
C
So
when
you
create
the
policy
for
dds,
when
you
convert
from
the
node
l
to
the
explicit
the
explicit
policy
right,
what
you
want
to
have
is
features
like
sorry,
a
property
like
list
privilege
and
the
minimality
of
the
policy
you're
generating.
C
When
you
are
auditing
the
system,
usually
you
manually
you're
able
to
verify
if
a
node
is
existent
or
not,
and
you
know
the
developer
in
that
case
can
inspect
and
correct
the
the
policy
in
accordance
to
what
is
able
to
to
see
and
debug.
C
When
you
generate
something
from
nodel,
I'm
expecting
developers
to
be
not
very
precise,
with
the
definition
being
a
little
bit
more
broad
in
permissions.
If,
if
I
can
say
so
and
then
I'm
a
bit
concerned
about
what
is
generated
from
the
nodel
as
a
result
of
that,
and
if
you
think
about
deployments
like
the
one
that
roger
was
suggesting
before,
if
you
have
a
huge
deployments,
so
not
just
a
public
subscriber
example,
things
get
complicated
to
manage
right.
C
So
I
think
you
will
you
should
probably
I
mean
we
should
probably
tackle.
Also
those
kind
of
properties.
B
A
Required
with
the
least
required
permissions,
because
nodel
has
no
idea
about
security
right,
the
l
is
only
a
declaration
of
your
nodes
interfaces
and
there
you
would
specify,
for
instance,
that
a
given
topic
for
a
given
node
is
that
a
node
on
a
given
topic
is
only
a
publisher
right.
So
it
would
have
only
a.
B
A
A
E
I
mean
I
so
I
get
what
gianluca
is
somehow
nevertheless
trying
to
convey-
and
I
think
this
somehow
matches
also
with
some
recent
work
we've
been
doing
again.
E
I
think
I
mentioned
that
a
subgroup
of
us
were
working
aside
on
a
separate
project
and
right
now,
I'm
happy
to
share
with
delivered
at
least
partially
a
finalized
product,
luca
I'm
referring
to
the
to
the
article
we've
been
working
on,
and
I
just
wanted
to
give
people
kind
of
like
a
heads
up
on
on
how
I
think
that
is
connected
to
nodel
and
also
to
what
gianluca
is
somehow
stressing
jeremy
about
somehow
assessing
policies
and
somehow
also
trying
to
reach
not
just
a
methodology
but
also
a
a
way
so
that
whatever
descriptive
security
or
whatever.
E
The
scripted
approaches
on
the
interfaces,
then
get
mapped
into
policies
are
somehow
assessed,
or
we
do
provide
guidelines
to
assess
that
in
a
systematic
manner.
So
so
maybe
let
me
let
me
try
to
get
straight
into
what
I'm
trying
to
to
say
and
also
that
this
is
one
of
the
topics
that
I
wanted
to
to
share
today.
So
here
it
is
so.
E
Unfortunately,
the
article
is
is
not
available
right
now
and
I
I
can't
I'm
afraid
I
can't
disclose
it
we'll
need
to
have
to
wait
until
it
gets
reviewed
by
the
conference,
but
I'm
more
than
happy
to
once.
That
happens
to
facilitate
a
copy
of
this.
If
anyone
wants
a
private
copy
and
he
or
she
can
keep
it
for
themselves,
I'm
happy
to
to
facilitate
it.
E
Essentially,
we
we
have
written
a
paper
about
s,
rosh
2,
renewing
some
of
the
capabilities,
and
this
is
a
joint
effort
between
roughing
luka
mikhail
and
I,
the
the
the
final
objective
we
wanted
to
achieve,
which
I
believe
it
has
been
achieved
is
to
provide
a
formal
methodology
for
assessing
security
in
roster,
while
providing
guidelines
on
how
to
approach
it,
and
we
have
done
so
by
essentially
splitting
it
into
a
number
of
steps.
First
doing
modeling
and
I
think
that's
where.
E
Yeah,
it's
it's
totally
slowly
broken
yeah,
sorry.
That
is,
I
need
to
change
browser
because
you
guys
may
know
that
firefox
and
google
me
does
not
get
along
very
nicely
yeah
well,
nevertheless,
so
so
I
I
won't
stop
now
but,
as
I
said
guys
ping
me,
if
you
need
a
copy
of
this,
and-
and
I
will
only
ask
you
to
keep
it
for
yourselves,
but
in
a
nutshell,
we
proposed
a
methodology
for
securing
roster
computational
graphs
composed
of
five
six
steps.
E
The
first
one
is
modeling
and
modeling
dives
down
into
actually
using
abstractions
to
indicate
of
of
the
security
process
of
abortion
computational
graph,
and
in
here
we
proposed
we
proposed
and
will
contribute
publicly
very
soon,
some
extensions
to
the
current
escrows
capabilities
to
monitor
network
interactions
based
on
dds,
well-known
security,
vulnerabilities
and
report
this
back.
E
So
this
is
one
of
the
features
we
are
contributing
on
top,
but
I
think
one
very,
very,
very
nice
one
would
be
to
leverage
florencias
and
jeremiah's
work
on
no
dl,
because
the
modeling
pieces
is
crucial
and
I
just
I
just
hope
we
can
have
a
conversation
dedicated
to
this
if
possible.
At
some
point,
not,
but
now
certainly
to
further
dive
into
some
of
these
ideas,
that
gianluca
was
conveying.
A
A
It
has
no
purpose
for
validating
your
your
graph
or
whatnot.
It's
only
for
modeling
information
and
modeling
it
in
a
way.
That's
totally
automated
from
the
launch
file
system,
allowing
absolutely
anyone
to
to
enable
the
whole
security
shipping
for
a
very
complex
system
out
of
a
single
launch
file
flag
right.
So
the
the
idea
also
with
nodel,
was
really
to
promote
security
to
to
the
masses.
C
A
I
may
say
so
and
to
do
so,
allow
them
to
use
secure
security
features
in
a
very
simple
way.
That's
that's
as
easy
as
a
switch
right,
as
opposed
to
figuring
out
your
your
key
store,
your
keys,
your
policies
and
whether
you
forgot
to
include
a
given
topic
or
not.
A
So
this
is
security,
roster
security
at
the
tip
of
your
finger.
Of
course,
it
doesn't
cover
all
of
the
security
use
cases,
and
especially
for
for
very
complex
system
or,
if
you're,
a
security
veteran.
You
may
want
to
to
do
things
your
own
way
and
that's
why
also
the
security
extension
to
the
to
the
launch
file
does
not
get
in
to
your
way.
It
allows
you
to
to
actually
provide
your
own.
Your
own
key
store,
your
own
enclave
in
in
the
rust
to
wording.
A
We
are
simply
going
to
work
toward
this
on
off
switch
at
the
moment,
meaning
we
want
to
make
a
documentation,
blog,
post
and
whatnot
to
to
raise
awareness
around
it.
And,
of
course
we
do
need
you
guys,
a
security
veteran
with
actual
use
cases
to
to
explore
the
the
limits
of
of
this
system
and
how
we
can
improve
it
and
make
it
better.
A
So
please
do
share
your
article
victor.
Whenever
you
can,
I
don't
know
if
we
can
find
a
way
to
to
share
it
securely
with
the
entire
working
room.
Yeah.
Maybe.
E
E
I
just
kindly
ask
for
people
not
to
not
to
publish
it
out
the
pdf,
at
least
for
now,
because
that
would
be
a
short
stopper
for
us
and
our
intentions
of
getting
this
widespread
and
accepted
the
the
objective
nevertheless
is
to
be
as
open.
E
As
always,
I
mean
the
contributions
to
the
roster
main
branch
should
land
very
soon,
and
the
the
article
itself
should
get
properly
disclosed
in
a
few
weeks
time
and,
of
course
the
intent
is
to
get
this
into
everyone's
essentially
desks
in
here
to
to
get
it
criticized
to
get
it
improved
and
to
have
a
first
kind
of
like
document
from
where
to
start
improving
things
right.
A
E
I
know
this
is
something
you
guys
have
been
pushing
forward
from
canonical's
side
and
and
the
reason
why
I'm
asking
is
because,
as
part
of
this
joint
effort
we
conducted
with
gen
luca
and
a
few
others
mika
and
rafi,
mainly
we
tackled
the
navigation
stack
and
that
is
already
quite
a
sighsy
graph.
E
I
may
say,
and
already
in
those
situations
issues
issues
arise.
So
I
was
just
wondering:
have
you
guys
decided
on
which
case
study?
Are
you
gonna
focus
on
the
terrible
four
and
on
that
line
of
of
asking?
Will
you
be
using
any
specific
single
board
computer
sbc?
E
So
have
you
decided
about
that
and
I'm
asking
this
also
for
security
concerns,
like
I
guess
the
usual
peak
would
be
the
raspberry
pi,
whatever
four,
I
think
we're
in
the
four
right
now
right,
but
I'm
just
I'm
just
asking
is:
is
there
any
interest
to
maybe
select
a
more
secure
underlying
hardware
by
default
to
show
the
use
case.
A
I
don't
have
any
any
stocks
on
the
on
the
title,
but
for
really
the
third
about
four
source
code
has
been
released
recently.
I've
also
shared
a
document.
A
That's
very
much
a
draft
regarding
this
whole
project
with
you
guys,
the
working
group,
and
I
believe
that
the
plan
at
the
moment
is
really
to
look
at
the
turtle
bot
for
simulation
and
try
to
enable
this
whole
nodel
and
ross
to
launch
secure
functionality
for
for
total,
but
four,
so
that
that
would
be
our
main
goal
at
the
moment
or
at
least
the
first
step,
because
not
only
is
that
nice
to
have
this
on
off
switch
security
switch
for
the
total
bot
for,
but
also
as
mentioned
during
during
the
presentation.
A
There
is
another
tool:
that's
no
dl
to
to
policy
and
that's
a
simple
python
script
that
automatically
generates
security
policies
from
from
modifs,
and
hopefully
we
can
leverage
that
as
well.
For
writing
the
policies
for
the
for
the
entire
titlebot
system.
E
Okay,
so
so,
if
I'm
getting
you
right
the
objective
of
this
and
by
the
way,
jeremy,
I
think
it's
a
fantastic
initiative
and
more
than
happy
to
to
support
it.
But
the
objective
is
that
essentially
you
will
you
will
get
up
to
speed
with
no
dl
and
as
basic
airforce
capabilities
in
the
base.
A
Let
me
let
me
build
on
on
my
answer
and
complete
my
answer,
that
that
is
our
main
first
step
right.
We
we
want
to
bring
up
to
run
securely,
but
then
we
want
also
to
to
move
toward
a
full-fledged
demo,
so
that
would
include
navigation,
but
not
only
navigation,
but
some
some
sort
of
scenario
using
autonomous
navigation.
So
something
like
a
turtle
but
for
roaming
in
a
in
a
room
with
obstacles
and
whatnot
and
doing
some
automated
test
tasks
again
our
main
objective
and
what
we
have
in
mind.
A
Capture
the
flag
kind
of
setup
that
that
fits
in
the
bag
right,
we
would
love
to
be
able
to
bring
a
turtle
bot
for
to
roscomm.
Japan
put
it
on
the
floor,
it's
moving
automatically
randomly
avoiding
obstacles
and
we
kindly
ask
the
internet
to
hack
it
right
that
that's
kind
of
the
crazy
idea.
A
A
E
So
I
think
yeah.
I
think
this
little
one
needs
me,
so
I'm
going
I'm
going
to
drop.
This
sounds
fantastic
and
thank
you
for
the
pointers
guys
I'll
catch
up
with
this.
A
few
ideas
just
came
to
mind
while
listening
to
you,
jeremy,
but
I'll
I'll,
digest
it
and
and
try
to
be
constructive
for
the
next
for
the
next
meeting
yeah.
This
sounds
this
sounds
great
and
I'd
love
to
see
a
hackable
turtle
for
navigating
around
rosco
in
japan.
A
B
And
again,
thank
you,
everyone
for
the
feedback
and
all
the
related
ideas
to
the
presentation
on
odl.
That's
actually
even
more
interesting
that
all
the
next
steps
that
I
suggested
is
everything
else
that
you
feel
like
it
could
be
an
additional
feature,
a
pull
request
or
anything
we
can
improve,
do
to
improve
nodel.
This
is
a
great
space
to
discuss
it
so,
as
termi
said,
feel
free
to
propose
it
for
next
meeting,
we
can
have
further
discussions
and
yeah
keep
building
it.