►
From YouTube: ROS 2 Security Working Group (13 Dec 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).
A
A
So,
okay,
so
welcome
to
the
security
working
group
meeting
for
December.
It's
great
to
have
you
all
here.
The
first
quick
thing
I
like
to
do
is
to
request
the
groups
approval
to
the
meeting
minutes
for
last
month's
meeting,
November
8th
so
I'm
in
22
and
they're
linked
on
the
agenda.
A
So
if
everybody
is
agrees
with
that,
then
we
will
consider
them
approved
and
move
on
to
our
next
item
in
our
agenda.
A
Okay,
so
we
have
today
presentation
from
new
members
of
the
group,
John,
Marco
and
Benjamin,
so
I'll.
Let
you
guys
introduce
yourself
and
give
you
the
floor
if
you
want
to
present
anything,
also
efficiently
go
right
ahead.
Thank
you.
B
Okay,
I'll
I'll
introduce
myself
and
then
Benjamin
Ben
introduce
himself
and
then
I
can
start
the
presentation,
I
guess
so
has
so
we
have
a
bats
on
my
tech
lead
at
the
amrc
in
Sheffield.
That's
the
advanced
manufacturing,
Research
Center
and
last
year
we
joined
the
Ross
industrial,
Consortium
and
I'm
sort
of
the
representative,
the
one
that
sort
of
talks
with
the
rest
of
the
European
Consortium
so
I've.
B
My
task
is
to
sort
of
look
at
what
we
call
novel
robotics,
which
is
anything
that
is
not
conventional
industrial
robotics
by
something
that's
more
of
Academia
based
and
we
try
to
push.
It
was
towards
industry,
and
that's
all
like
my
role.
B
But
the
reason
why
we're
here
is
that
one
of
the
approaches
that
we
started
this
year
is
involved
as
sort
of
the
transition
from
Ross
one
to
Ross
still
because
I've
got
quite
a
long
experience
on
lost
one
but
I
never
touched
roster,
and
it
was
about
time
for
for
us
to
start
so.
I
I
don't
have
much
if
any
experience
in
security,
while
Ben
I
think
comes
from
the
sort
of
opposite
and
the
perspectives
yeah.
It's
a
way
of
experience
in
Ross,
but
it's
more
of
an
excellent
security.
B
So
I
designed
one
work
package
on
that
project
that
we're
working
on
just
to
look
at
the
security
sort
of
side
of
Ross
and
how
that's
implemented
and
just
if
you
could
see
a
lot
almost
like
a
trade-sided
to
see
the
strengths,
the
and
the
weaknesses
and
and
that's
what
basically
Ben
has
done
as
part
of
this
project
and
I.
Think
I
can
leave
that
I'm
telling
you
a
bit.
So
you
can
introduce
yourself
and
let
me
start
with
that
presentation.
C
Yes,
thank
you,
hello,
I'm,
Ben,
Morrow
I've
been
yeah
as
John
Mark
I
said
I've
been
you
know,
looking
into
the
using
the
ross2
security
architecture,
you
know
practically
to
secure
a
robot
in
you
know
an
industrial
environment
where
maybe
it's
more
important
than
sometimes
that
things
are
actually
secure
and
yeah
I
mean
I.
C
You
know,
I
I
found
a
couple
of
problems,
but
it's
it's
certainly
a
big
improvement
over
the
Ross
one
situation
where
there's
no
security
at
all,
so
you
know
so
I've
done
I
mean
I've
done
a
presentation,
so
I
think
I'll
just
start
and
explain
things
as
I
go
along.
It's
probably
easiest.
C
Can
everybody
see
that
yeah
yeah,
okay,
cool
okay,
so
my
part
of
the
project
was
basically
to
take
a
robot
that
had
been
set
up
to
run
with
Ross
to
and
to
you
know,
attempt
to
implement
the
Ross
to
security
and,
in
the
course
of
doing
that,
obviously
you
have
to
set
up
the
key
stores
and
the
certificates
and
everything
and
I
well
I
ran
into
a
problem
which
I
will
explain.
C
Excuse
me,
if
I'm
telling
you
things
you
already
know
which
I
probably
am
so
Ross
2
security
is
based
on
DDS
security
and
the
DDS
security
architecture
is
based
on
x509
certificates,
open
SSL
certificates,
so
DDS
the
way
the
way
DDS
does
security
is
there
are
two
root
certificates,
there's
one
that
certifies
identities
and
there's
one
that
certifies
permissions
and
as
far
as
DDS
is
concerned,
they're
completely
separate
the
trust
change
to
certify
an
identity
and
permissions
document
are
not
related.
C
They
don't
need
to
be
connected
at
all,
which
is
slightly
complicated,
and
but
that's
how
I
mean
that's
how
the
DDS
people
chose
to
do
it,
and
so
that's
how
that's
this
framework
that
Ross
has
to
work
within,
given
that
you're
using
DDS
as
your.
C
The
Ross
security
tool
when
it
sets
up
a
key
store,
obviously
because
you
thought
that
this
was
too
complicated
or
something
it
actually
unifies.
Those
two
certificates,
the
identity
and
the
permissions
certificate
authorities
into
a
single
certificate
that
lives
at
the
root
of
the
key
store,
and
it
creates
some
links
to
them
in
the
key
store
so
that
it
fulfills
both
functions.
C
C
Normally,
this
isn't
a
problem.
The
nodes
publish
their
permissions
documents,
the
other
nodes
receive
them.
They
verify
the
signature
which
goes
against
the
against
the
authority
that
they
have
that
Authority
is
set
up
for
them,
as
the
permissions
Authority,
so
they're
quite
happy
to
accept
the
permissions
documents
and
everything
works
and
everybody's
happy.
C
However,
what
happens
if
you
have
an
enclave
that
decides
to
misbehave?
You
know
the
whole
point
of
having
security
is
so
that
you
can
start
to
separate
the
different
parts
of
a
robot
from
each
other.
So,
for
example,
if
a
user
has,
you
know
they're
running
RVs
on
their
laptop
and
you
maybe
don't
quite
trust
their
laptop,
it's
a
user's
machine,
but
you
want
to
give
them
read
access
to
the
robot,
so
you
start
setting
up
ACLS
so
that
they
only
have
read
access.
C
They
can't
move
the
robot
whatever
there
are
all
sorts
of
Access
Control
decisions.
You
know.
If
we
have
access
controls,
we
need
to
be
able
to
use
them
and
they
need
to
work
so
assuming
that
the
permissions
have
been
set
up
to
allow
different
parts
of
the
robot
different
amounts
of
access
to
each
other.
C
C
E
F
C
B
C
C
You
can't
sign
it
with
the
with
the
certificate
Authority
Key,
but
it
can
sign
it
with
its
own
private,
with
its
own
certificate,
and
then
it
publishes
that
document
over
DDS
and
the
other
nodes
receive
it
and
they
attempt
to
verify
it
and
because
there
is
a
chain
of
trust
down
from
The
Joint
Authority
through
the
node's
own
certificate
to
the
new
document.
C
They
believe
that
it's
they
believe
that
it's
authentic,
so
The
Enclave
certificate
is
signed
by
The
Joint
certificate
in
its
role
as
identity,
but
the
other
nodes
are
trusting
it
in
its
role
as
permissions,
and
so
the
the
certificate
is,
the
the
malicious
document
is
believed,
even
though
it's
not
supposed
to
be
because
because
the
chain
of
trust
goes
through
the
identity
certificate.
C
If
the
the
solution
I
mean,
the
straightforward
solution
is
to
have
two
certificate
authorities
as
DDS
had
in
the
beginning
and
then,
although
the
node
can
still
sign
a
document
with
its
Enclave
certificate,
that
document
is
no
longer
trusted,
because
the
Enclave
certificate
is
no
longer
signed
by
the
permissions
Authority.
It's
only
signed
by
the
identity.
C
Which
you
know
restores
the
security
you
know
restores
the
ability
to
set
proper
ACLS
on
the
nodes,
so
I
mean
I
was
I
I.
Actually,
you
know
worked
this
out
when
I
was
thinking
about
rollover
of
certificates
and
and
signing
certificates
with
other
certificates,
so
that
you
can
roll
over
the
route
and
so
on
and
I
was
thinking
backwards
through
the
problem,
I
said
actually
I.
Think
I
can
do
this
here.
I
think
I
can
cheat
I.
C
Think
I
can
get
around
the
security,
so
I
actually
set
up
a
script
to
demonstrate
it
because
I,
you
know
I
wasn't
entirely
sure
it
would
work.
So
this
is
a
I,
don't
know
if
how
well
it'll
come
through,
but
this
is
a
video
of
actually
running
a
test.
C
That'll
do
okay,
so
it
creates
a
new
key
store.
C
D
C
Know
demonstrate
it
for
themselves,
but
the
way
this
is
supposed
to
be
set
up
is
that
the
talker
is
talking
and
The
Listener
is
not
allowed
to
listen,
it
doesn't
have
permission
to
listen
to
the
talker,
so
it
runs
the
nodes
they
find
their
security
and
the
listener
is
not
allowed
to
listen.
C
The
Listener
is
correctly
failing
to
be
able
to
subscribe.
The
publisher
of
the
talker
is
publishing
and
The
Listener
is
not
allowed
to
subscribe,
then
acting
as
a
malicious
listener
load
I
take
the
permissions.
Xml
and
I
just
change
the
topic,
so
the
listener
was
allowed
to
subscribe
to
something
else,
and
it
just
changes
the
topic
to
the
to
the
topic.
C
It's
not
supposed
to
be
allowed
to
subscribe
to
it,
re-signs
the
document
with
its
own
Enclave
key
and
then
when,
when
we
run
them
again,
it's
successfully
able
to
subscribe,
even
though
it's
not
supposed
to
be.
C
Okay,
that
I
think
I'll
stop
there
for
a
second,
because
if
you
had
any
questions,
I
mean
there
were
a
couple
of
other
things
that
I
that
might
be
worth
talking
about,
but
I
think
that's
worth.
Maybe
discussing
for
a
minute.
Do
you
think.
G
F
Okay,
so
for
the
x509
certificate
standard
there
is
a
flag
denoting
whether
the
certificate
is
authenticated
to
be
a
certificate
Authority,
and
so
particularly
like
for
web
development.
You
know
when
you
have
casigning
SSL
service.
F
You
want
to
be
cautious
that
you're
that
that
CA
isn't
signing
authenticating.
Another
CA
to
like
you
know,
extend
the
chain
of
trust
further
to
truncate
that
the
ca
can
deliberately
choose
to
only
sign
certificates
that
do
not
have
the
certificate
Authority
flag
set.
So
then
the
chain
of
trust
truncates
there
from
what
I
remember
I
thought
we
were
using
the
x5x9
python
library
to
deliberately
disable
that
flag
for
certificates
for
Toc
for
the
enclaves.
But
maybe
did
you
find
that
that
was
that
wasn't
the
case.
No.
C
The
when
you
sign
the
permissions
documents
you're
using
S
mime,
the
permissions
document
is
not
a
certificate.
It's
just
an
XML
certificate
signed
with
s
mime,
which
means
that
it
is
not
supposed
to
be
signed
by
a
certificate
Authority
at
all.
It's
supposed
to
be
signed
by
a
plain
endpoint
certificate,
so
the
the
signature.
F
For
the
oh,
so
this
is
an
implementation
error
in
in
no
no,
it's.
C
Not
it's
it's!
It's
a
it's
a
possibly
a
misunderstanding
of
the
function
of
the
of
the
function
of
the
different
certificates
involved,
I'm,
not
sure
so
as
the
as
the
ross2
security
tool
creates
the
key
stores
and
so
on.
This
certificate,
Authority
certificate
has
has
capath
zero.
It's
it's
not
allowed
to
sign
any
sub-authorities
when
the
permissions
document
is
signed
directly
by
the
certificate
Authority,
that's
not
actually
how
it's
supposed
to
work.
You're
supposed
to
always
have
an
intermediate
certificate
by
x509
Design.
C
So
the
idea!
Well,
if
you
go
back
to
the
original,
the
idea
here
is
that
normally
you
would
have
the
permission,
certificate
Authority
and
then
you
would
have
sub
certificates
issued
perhaps
to
individual
administrators
who
had
authority
to
sign
permissions
documents,
a
personal
certificate
for
a
you
know,
for
a
systems
administrator,
and
then
they
would
sign
the
permissions
document
with
their
personal
certificate.
F
Yeah,
the
unclean
certificates-
oh
sorry,
the
The
Enclave
certificates
shouldn't
be
able
to
sign
anything
if
they're
signing
the
FM
signature,
then
that
signature
doesn't
match
with
the
root
CA,
though,.
C
C
F
No,
you
should
you
should
be
able
to
TLS.
You
can
do
that
if,
if,
if
you're,
just
a
RSA
or
a
elliptic,
curvy
e
public
TV,
you
just
have
your
key
fair
and
it
doesn't
mean
that
anything.
You
sign,
you
can't
sign
any
certificates,
but
you
should
be
able
to
the
helmet
Exchange.
C
I
think
I
think
you
still
need
well,
certainly
as
ros2
security
creates,
the
certificates
that's
not
implemented,
maybe
maybe
it
could
be
fixed
just
by
changing
the
flag.
I
didn't
I
didn't
think
that
you
could
I
thought
that
you
actually
needed
the
sign
data
flag
in
order
to
do
the
certificate
exchange,
because
you
have
to
sign
diffie-hellman
stuff
as
part
of
the
exchange.
Don't
you
even.
F
Certificate
Authority
flag
doesn't
doesn't
disable
you
from
doing
different
elements
where.
G
F
And
then
line
140
this.
This
is
the
case
where
this
yeah,
the
EA
certs,
are
acting
as
certificate
authorities
and
if
we
found
the
similar
function
for
invoking
an
enclave,
cert
I
think.
F
C
If
you
look
at
the
chain
of
trust,
it's
only
the
first
it's
so
this.
This
certificate
is
not
a
certificate
Authority,
but
it's
allowed
to
sign
documents.
F
Why
is
validator
taking
that?
Accepting
that
it
should
look
at
the
certificate,
the
x509
certificates
for
The
Enclave
certificate
and
realize
it's
not
a
CA,
so
they.
F
F
I
know
you
can
sign
it,
but
why
is
the
validator
accepting
I.
C
D
G
C
F
Okay,
I
thought
I
thought
the
the
the
evaluation
for
the
permission
files
for
going
through
the
same
format
as
if
it
was
a
certificate.
No.
F
C
I
mean
looking
at
the
looking
at
the
flags
the
this
this
this
this
flag
is
the
one
you're
talking
about.
Isn't
it
this
digital
signature,
flag,
you're
saying:
if
can
you
turn
that
flag
off
on
The,
Enclave
certificate
and
I?
Think
the
answer?
Is
you
can't?
Because
you
can't
do
anything
without
it?
You
can't
do
you
can't
prove
your
identity
without
it,
because
the
way
you
prove
your
identity
is
by
signing
stuff.
C
Because
the
ca
shouldn't
have
that
flag,
no
I
can't
remember
I,
can't
remember:
there
are
certificates
that
don't
have
that
flag.
I,
think
I,
think
intermediate
Cas
don't
have
that
flag
because
they
have
key
sign
instead,.
F
C
F
Yeah
we
we
just
did
some
links
in
the
beginning
to
plug
in
their
own
certificate
authorities,
to
do
that
yeah
without
having
to.
C
D
C
I
mean
it
would
be
nice
to
be
able
to
have
a
single
authority
to
that.
You
could
change
from,
but
it's
it's
difficult
to
see
how
it
works,
because
the
the
simple
Act
of
signing
a
certificate
with
the
permissions
Authority
gives
that
certificate
permission
to
set
any
permissions
on
the
whole
robot.
It's
actually
quite
a
serious
act,
signing
something
with
the
permissions
Authority.
C
D
C
Yeah,
okay,
hang
on,
so
there
are
a
couple
of
more
a
couple
of
more
minor
questions
to
do
with
how
the
key
store
was
set
up
that
I
came
across.
C
E
I
ate
a
point
that
might
be
related,
we
did
I,
don't
know.
If
you
have
the
agenda
there,
it
might
be
somehow
related
or
relevant
on
on
Broad
Street
design.
E
So
I
don't
know
a
year
and
a
half
ago,
or
so
we
try
to
push
for
a
new
feature
on
Rush
2,
which
is
to
store
the
private
key
of
the
of
the
enclaves
in
in
a
hardware,
secure
module
or
hard,
or
rather
have
the
ability
to
do
so
using
this
pkcs
11
protocol.
E
We
got
as
far
as
making
a
design
proposal
here
and
then
actually
we
have
a
pull
request
on
rmw
Fast
rtps,
which
is
the
the
connector
between
fast
DDS
and
and
ros2,
where
we
implemented
this
and
in
in
our
own
Fork.
We
have
it
implemented
and
we
have
some
some
clients
actually
doing
that.
E
I,
don't
know
if
you
have
seen
this
before
or
not,
but
the
thing
is
that
you
store
the
private
key
on
a
hardware,
secure
module
that
then
the
rmw
can
retrieve
when
neat
or
fast
EDS,
rather
can
retrieve
when,
when
needed,
using
a
film
or
or
kind
of
a
password
right.
So
it
makes
the
it
makes
systems
more
secure.
E
E
I
think
that
could
be
relevant
from
from
for
what
you
were
saying
before
right
in
a
way
and
we
actually
were
intending
to
try
to
or
push
that
forward,
I
mean
do
whatever
we
need
to
do
to
to
make
that
feature,
come
into
the
main
line,
meaning
decide
on
interfaces
on
the
upper
layers
and
so
on
with
the
working
group
here.
C
C
C
Yeah
yeah,
you
have
the
The
Enclave
certificate.
Private
keys
are
definitely
quite
a
weak
point.
I
mean
they're
easy,
the
the
you
need
good,
revocation
mechanisms,
don't
you
always
which
I'm
not
sure
has
quite
been
thought
about,
but
I
didn't.
C
D
C
E
E
C
I
mean
this
this
that
actually
ties
somewhat
into
the
next
thing.
I
was
gonna,
try
and
talk
about,
which
is
to
do
with
generating
The
Enclave
certificate
sure.
So,
if
I
share
screen
again.
C
This
one,
so
normally
when
you,
when
you
generate
a
x509
certificate
for
a
web
server
or
whatever
you
start
by
generating
your
private
key
locally,
you
generate
a
public
key
from
the
private
key.
You
generate
a
certificate
signing
request
from
your
public
key.
You
send
that
off
to
the
certificate
Authority,
they
sign
it
and
it
comes
back
as
a
certificate
that
you
use
and
your
key
always
stays
in
your
possession
and
their
key
always
stays
in
their
position,
and
you
never
have
to
switch.
C
You
never
have
to
move
keys
from
device
to
device.
I
mean
x509,
have
put
a
lot
of
work
into
making
sure
that
this,
the
Certificate
request
and
the
certificate
are
both
safe
to
transport.
In
fact,
in
the
clear,
if
you
want
to
as
long
as
you
end
up
with
the
right
thing
signed.
C
The
way
we're
asked
to
security
does
it
is
when
you
run
create
Enclave,
it
creates
The
Enclave
certificate
and
signs
it
in
a
single
step,
which
means
that
you
then
have
to
choose,
am
I
doing
this
on
the
machine
where
it's
going
to
be
used
or
am
I
doing
it
on
the
machine
that
has
access
to
the
Authority
Key,
they
ought
to
be
separate
machines
and
yeah.
E
C
No
I
think
this
is
I
think
this
is
quite
a
I
mean
it's
I
think
it's
maybe
a
little
bit
of
a
an
approach
change.
You
know
that
that
you
need
a
Security,
Management
setup
that
is
isolated
from
the
robot
and
has
private
keys
for
the
certificate
authorities
and
everything
else
so
yeah
anyway.
This
is
this
is
where
I
this
is
where
I
came
to.
You
know:
where
do
I
run
this
command?
C
If
I
run
it
on
in
My
Signing
system,
then
I
have
to
transport
the
private
key
back
to
the
robot,
which
is
bad
security
practice.
If
I
run
it
on
the
robot,
then
I've
got
to
put
my
certificate
Authority
Key
on
the
robot,
which
is
even
worse
so
I
mean
you
know.
It
just
needs
options
to
generate
the
request
and
do
the
whole
dance
in
the
right
order.
With
everything
you
know.
F
Yeah,
the
the
processor
of
this
tooling
that
I
wrote
with
keyment
and
calm
armor
I
I.
That
was
my
initial
approach,
where
I
sort
of
have
a
workspace
and
everything
was
sort
of
staged
in
the
file
system,
and
so
you
could.
You
could
have
an
intermittent
stage
with
the
certificate
requests,
signing
requests
and
then
so
so
then
you
could
like
kind
of
manage
that
out
of
bands
from
the
the
CLI
based
on
how
you
were
exchanging
these
files.
G
F
The
private
key
for
the
robot
would
never
have
to
be.
It
could
be
generated
on
the.
F
C
Yeah
I
mean
presumably,
if
you're
talking
about
these
Hardware
security
modules,
I
think
I
mean
I,
don't
really
know
how
they
work,
but
I
think
quite
often
they
insist
on
generating
their
own
key.
Don't
they
and
they
don't
ever
give
it
to
you
so
it
you
know,
you'd
have
to
take
you'd
have
to
use
the
one
that
it
you
know
that
it
made
for
you.
C
So
yeah
I
mean
it's
just
you
know
it's
all
detail.
The
architecture
is
all
there
and
can
be
used,
and
you
know
it
just
needs
I
think
it
just
needs
a
bit
more
yeah
I
mean
and
then
some
Minor
Details,
you
know
like,
like
none
of
the
private
keys
are
stored
encrypted
and
they
can't
be.
C
You
know
they
really
should
be
a
certificate.
Authority
private
key
should
never
be
on
disk
unencrypted.
C
You
know,
and
and
and
just
the
idea
of
having
a
separate
signing
key
store
from
your
running
key
store
and
and
tooling
that
can
pull
out
the
right
files.
If
you,
if
you
just
run
through
the
tutorial
for
the
for
the
setting
up
the
security,
you
end
up
copying
your
certificate,
Authority
private
key
onto
the
robot,
and
that's
not
really
something.
We
want
to
encourage.
G
C
But
if
you
just
even
if
you
just
copy
The
Enclave
directory
well
yeah,
you
can
just
copy
The
Enclave
directory
and
that,
but
then
you
have
to
follow
the
Sim
links,
because
it's
all
Sim
linked.
You
have
to
resolve
the
Sim
links.
D
C
Yeah
I
I
just
think
it's
not
it's
not
it.
You
know
it
wasn't
entirely
clear.
If
you
just
follow
the
you
know,
if
you
just
follow
it,
it
just
says:
skip
the
whole
directory
which
works,
but
it's
not
yeah
anyway,
that
that
was
all
really
just
you
know,
I
mean
even
I
mean
the
conclusion.
I
came
to
really.
C
Is
that
if
you
take
it
as
it
stands
right
now,
You
can
generate
a
key
store
with
a
single
Enclave
which
has
full
robot
permission
and
that
and
then
you
treat
that
whole
key
store
as
a
shared
secret
and
just
copy
it
to
all
your
robot
nodes.
Even
that
gives
you
a
significant
security
increase
over
Ross
one
or
unsecured
Ross
2..
You
know,
you've
got
pre-shared
secret
level.
Security.
F
For
me
from
your
experience,
I
I
met,
but
this
is.
This
is
probably
not
a
pre-existing
problem
that
many
other,
like
iot,
vendors
or
even
web-based
ecosystem
is
has
probably
tackled,
like
I.
Think,
there's
Key,
Management,
Frameworks
I
think
trying
to
remember
these
the
most
popular
one,
that's
like
from
key,
I
o
or
whatnot,
but
in
terms
of
doing
all
the
logistics
and
and
transporting
and
managing
certificate
signing
requests
and
having
us
having
a
Consolidated
API
to
do
that
kind
of
middleware
Exchange.
F
This
is
I
think
this
is
something
that
maybe
we're
better
off
leaning
on
that
infrastructure
rather
than
you
know,
home
brewing
our
own
own
stuff
in
Python.
Here.
C
F
Can
you
post
these
slides
and
then
your
script
as
well,
and
then
things
yeah.
C
A
F
I
think
I
think
the
best
thing
I'd
be
is
to
to
maybe
file
a
new
ticket
on
the
restaurants,
and
then
you
could
like
attach
your
your
PDFs
and
your
and
your
script
as
well
as
like
a
summary
of
the
name
of
the
main
pain
points.
Yeah.
E
Should
we
have
some
action
point
to
do
about
this
at
least
put
a
note
on
the
documentation
saying:
do
not
deploy
the
CI
certificate
private
Keys
into
the
robot,
something
right,
I,
don't
know.
E
E
Improving
a
bit
on
the
raw
2
documentation,
even
taking
a
look
at
the
tutorial.
Maybe
if
we
can,
you
know,
split
the
the
enclave
and
and
the
key
store
you
know
having
one
for
signing
and
one
for
running,
and
then
you
know
saying
that
you
should
deploy
the
one
from
running.
This
is
still
not
perfect
because
of
what
you
described
right,
that
you
can
still
sign
things
with
a
malicious
note,
but
it's
definitely
better
than
what
we
have
now
so.
E
Not
really
think
any
further
than
that
yeah
exactly
so,
and
that
that's
kind
of
the
point
right
that
we
need
to
encourage
the
use
of
security
because
from
our
experience-
and
we
do
some
consultancy
on
projects
using
those
two
actually.
No.
But
everyone
says
that
they're
very
concerned
with
security
and
nobody
ever
uses
it
so
kind
of
need
to
make
it
very
easy
for
them.
No
way.
E
And
regarding
this
Hardware
secure
module,
feature
proposal,
I
I,
don't
know
how
to
be
honest,
but
the
person
that
opened
the
pull
request
used
to
work
here
and
he
was
the
one
attending
the
security
working
group
meetings.
And
then
we
have
a
had
a
period
where
we
are
not
attending
so
I
actually
don't
know.
E
What's
the
process
to
kind
of
move
things
along
or
try
to
try
to
work
on
things,
I
don't
know
if
we
should
have
the
discussion
on
the
design
should
we
prepare
our
rep
proposal,
like
which
kind
of
seems
the
trend
right
now
in
Route,
2
I,
don't
know.
F
Today,
sorry,
the
design
docs,
the
last
two
design
docs,
that's
currently
houses
the
equivalent
of
what
would
have
been
the
Reps.
The
Ross
enhancement
was
also
bar
on
the
security
front.
So
there's
the
three
design
docs
on
on
Rusty
design
that
you
can
take
a
look
at
and
then
I
would
propose
Maybe
modifying
that
opening
up
the
pr
and
then
that
way
we
have
like
a
more
concrete
high
level
overview
of
How
It's
expected
to
integrate
with
the
rest
of
the
user
experience
like
are
they?
F
Are
they
controlling
where
the
keys
are
located
the
environment
variables?
Or
is
this
some
extra
command
large?
How
is
this
expected
to
be
found
in
the
rmw
layer
to
like
notify
the
DDS
layer
where,
where
the
keys
are
is
it
is
it?
Is
it
a
file
path
or
to
the
unique
Linux
resource,
or
is
it
like
in
specific
you
ID
I'm,
not
sure
how
this
is.
F
How
this
is
that
software
Hardware
boundary
is
communicated
to
the
so
I
would
I
would
recommend
the
going
over
the
design
docs
currently
and
then
opening
a
PR
and
modifying
them
to.
E
Okay,
I
will
try
to
then
I.
Don't
know,
go
over
these
pull
requests
again.
Maybe
if
there
needs
to
some
update
or
something
and
should
I
just
pin
your
browser
to
to
take
a
look
at
it
or
should
it
be
someone
else,
I
I,
don't
know.
F
You
can
thank
me,
I
think.
Do
we
also
have
a
a
security
tag?
I
thought
we
had
a
security
group
working
group,
but
maybe
I'm
forgetting
about
that
for
a
team,
GitHub
team
thing.
G
F
Something
happened,
I
guess,
but
yeah
there
is
the
end
the
way
to
notify
everyone.
That's
a
member
of
the
written.
G
G
A
So
I
invite
you
also
to
join
the
Matrix
chat
for
the
group.
G
E
A
Okay,
no,
if
you
guys
have
something
else,
we're
almost
at
the
time
and
I
yeah.
It's
a
great
thing
that
now
we
have
like
the
of
well
asynchronous
channels
to
keep
working
on
this.
G
E
F
Benjamin,
when,
when
you
create
that
attack,
get
please
please
add
me
at
Rapha
cell
I
really
like
to
maybe
kick
generate
a
night
python
notebook
using
our
current
API
to
replicate
the
exact
scenario.
Okay,
it.
F
I
I'm
sorry
Benjamin
I
missed
your
your
beginning.
Your
introduction,
where
are
you
from.
C
F
B
Better
so
yeah
we
sort
of
my
role
is
the
one
I've
mentioned
at
the
beginning,
but
I
just
said
he
probably
missed
it.
We
so
my
role
is
to
sort
of
look
at
the
what
we
call
novel,
robotic
side
of
Robotics,
which
is
anything
to
do
with
robots.
That's
not
traditional
industrial
robots,
so
you
know,
like
a
tradition
like
cooker
robots
that
just
do
like
KRL
or
like
ABB
robots
are
only
used
proprietary
languages.
B
So
we
look
at
we're
trying
to
push
this
new
so
by
the
way
I.
Don't
know
if
you
know
what
the
recountable
center
the
mrcs
and
what,
if
you
know
what
Center
is
so
basically
partially
funded
by?
B
We
are
owned
by
the
University
of
Sheffield
by
a
partially
funded
by
the
government
through
accountable
fundings,
and
we
try
to
sort
of
push
research
for
the
UK
sort
of
market
and
as
and
that's
part
of
one
of
these
findings
this
year,
we're
trying
to
we've
done
a
few
projects
on
Bros
one,
but
now
we're
trying
to
to
push
the
sort
of
the
use
of
Ross
too
and
then,
ideally,
we
can
sort
of
publicize
or
disseminate
all
those
information
to
allow
Industries
around
the
UK.
B
So
predominantly
we
are
a
research
center
and
we
are
one
of
our
goals
at
the
moment
is
to
push
Rose
more
towards
industry,
because
you
guys
probably
know
better
than
me
is
used.
A
law
in
Academia
Industries
are
quite
reluctant
and
I
guess
that's
the
reason
why
Boss
2
was
born
to
answer
all
there's
the
issues
of
all
the
problems
the
industry
is
hard
with.
B
I
would
lost
one
so
now
we're
trying
to
sort
of
disseminate
like
study,
luster
a
bit
more
understand
how
the
weaknesses
and
strengths
and
then
push
that
dissemination
to
the
UK
industry.
B
So
yeah
we
we're
going
to
do
as
a
company
sort
of
wise
what
we're
going
to
try
and
walk
across
to
have
been
more.
This
is
the
first
project
that
we
officially
done
and
lost
during
them.
B
Yeah
definitely
so
we
are
quite
big
I'll
find
the.
B
Link
to
the
website,
we've
got
different
centers
across
the
UK,
we're
both
in
Sheffield,
but
we've
got
a
lot
of
different
subjects
or
we
looked
at
what
we
call
Integrated
manufacturer,
which
is
basically
integration,
control
system,
robotics
security,
IO,
iot
and
factor
of
the
future
sort
of
things.
And
then
we've
got
the
centers.
B
The
local
compost
area,
I've
got
I'll,
just
have
a
look
casting
medical,
so
yeah
we've
got
different
centers
we
specialize
in
robotics,
but
that
our
Center
called
Goliath
difference
and
there's
a
lot
of
different
things
awesome,
and
from
last
year
we
joined
the
it
was
industrial
Consortium
so
with
the
hope
of
gaining
more
knowledge
with
you
from
you,
but
also
sharing
it
yeah
with
your
clients.
F
All
right,
I
I,
hope
to
see
you
around
the
The
Matrix
Channel.
We
can
continue
iterating
on
these
sixes
really
soon.
A
Yeah
and
for
the
action
point
so
feel
free
to
add
anything
else
that
we
don't
on
the
agenda
I,
usually
to
prepare
the
meetings,
the
minutes
I
go
by
the
recording
later
on,
but
just
so
to
work
here
together.
If
there's
anything
else,
you
decided
to
take
upon
yourself,
like
I,
saw
Eduardo
added,
improving,
secure
examples,
almost
two
dogs
so.
F
You
can
add
me
to
looking
into
the
splitting
the
Cas
and
verifying
the
the
issue.
The
the
chain
of
drugs
I'll
definitely
open
that.