►
From YouTube: CNCF SIG Security 2020-05-27
Description
CNCF SIG Security 2020-05-27
A
A
B
A
B
B
C
B
B
C
C
B
C
C
C
C
C
B
E
B
B
C
B
C
C
Okay,
I
think
we
can
get
started.
We
seem
to
have
quite
a
good
number
of
people
here
and
we're
already
almost
five
minutes
in
so
today
is
gonna,
be
a
presentation
paul
and
a
few
other
colleagues
here
from
are
gonna
talk
to
us
about
pasek
platform
extraction
for
security,
dealing
with
tpms
hardware,
security
modules
stuff,
like
that
all
the
good
stuff-
and
I
believe
you
guys-
are
submitting
this
for
sandbox.
What's
it
right,
that's
correct!
Yes,.
F
B
Okay,
well
thanks
very
much
brandon
hello.
Everyone
thanks
for
allocating
the
time
on
the
agenda
for
me
today,
so
I'm
going
to
present
parsec,
which,
as
we've
said,
that
has
now
been
proposed
for
donation
to
cncf
as
a
sandbox
project.
The
pull
request
is
open
with
our
proposal
document
currently,
and
it
is
a
security
focus
project.
B
So
so
so
I'm
excited
now
to
be
presenting
it
to
the
security
sig
quick,
who
am
I
my
name's,
paul
howard,
I'm
a
solutions
architect
here
at
arm
nominally
based
on
the
armed
campus
in
cambridge
uk,
a
few
of
my
vital
signs
here.
If
you
want
to
connect
or
get
in
touch,
I'm
paul
dot,
howard
at
arm.com,
I
am
on
the
cncf
slack
as
well
as
on
the
docker
community.
Slack,
so
do
feel
free
to
get
hold
of
me
there
or
via
any
of
the
other
ways
shown
here.
B
My
role
in
parsec
is
that
I
am
a
maintainer
and
I
provide
some
technical
steering
for
the
contributions
that
arm
is
making
and
also
we're
very
fortunate
to
have
some
of
my
arm.
Colleagues
on
the
call
today,
including
yug
and
johnerts,
both
of
whom
are
regularly
making
code
commits
into
parsec
and
those
names
will
become
familiar
to
anyone
who
has
been
involved
or
wants
to
get
involved.
B
B
The
volume
of
data
from
iot
is
growing
and
with
that
growth
comes
a
need
to
process
and
gain
insights
and
actions
from
that
data
locally,
without
a
high
cost
and
high
latency
backhaul,
and
it
means
that
this
edge
layer
where
we
might
traditionally
have
done
nothing
more
than
say
a
protocol
translation
is
now
a
place
where
we're
doing
analytics
we're
doing
machine
learning.
It's
a
place
where
we're
deploying
complex
workloads,
it's
becoming
a
more
elastic
and
cloud-like
layer.
B
And
in
a
more
elastic
and
cloud-like
layer,
we
want
to
have
cloud-like
development
and
deployment
practices
we
want
to
containerize.
We
want
to
orchestrate.
We
want
to
make
use
of
that
huge
momentum
that
we've
built
up
with
cloud
native
development
practices,
and
we
want
those
practices
to
succeed
for
us
at
the
edge.
B
B
It's
also
a
challenge
because
there
is
diversity
and
fragmentation
of
those
host
platforms,
especially
around
security.
So
there
are
different
routes
of
trust,
different
provisions
for
secure
services
like
key
storage
and
cryptography
and
with
those
different
provisions
we
get
different
apis
and
that
creates
type
coupling
problems.
Because
there's
now
a
need
to
understand
these
platform,
hardware
features
in
order
to
access
them,
and
this
just
isn't
what
we
want.
B
So
what
we
want
is
agnostic
solutions.
We
want
solutions
that
are
divorced
and
decoupled
from
all
this
detailed
physical
platform,
knowledge,
and
not
only
that,
but
we
want
to
avoid
any
notion
of
any
single
workload
being
the
sole
resident
of
the
hardware
platform.
So
we
want
workloads
to
be
decoupled
from
physical
hosts.
B
B
So
we
saw
eye
to
eye
on
the
problem
and
on
what
roughly,
what
was
needed
to
address
it.
So
we
got
together
and
we
decided
to
work
together
to
create
something
in
the
open
source
community
and
the
executive
summary
of
how
those
conversations
went
was
well.
Do
we
need
to
build
anything
at
all
and
really
the
answer
to
that
was
yes,
because
again,
the
existing
apis
were
fragmented
specialized.
B
And
then
the
next
question
is:
if
we're
going
to
have
this
common
api,
then
then
what
is
it?
What
should
it
look
like
for
this?
We
mined
the
psa
the
platform
security
architecture.
This
is
something
that
arm
had
previously
defined
as
being
a
holistic,
end-to-end
approach
to
security
for
iot
platforms
and
inside
this
architecture.
There
are
api
suites
available
and
one
of
those
apis
is
the
psa
crypto
api.
It
ticked
lots
of
boxes
for
us
in
that
it's
modern,
strongly
specified
its
platform.
B
If
I'm
an
application
developer,
give
me
a
simple
and
portable
way
to
consume
the
best
available
secret
storage
or
cryptographic
services.
On
my
platform
in
my
preferred
programming
language,
that
is
a
use
case,
that's
loaded
with
all
sorts
of
requirements
and
we'll
talk
about
how
parsec
intends
to
address
them.
It's
also
worth
remembering
here.
B
These
use
cases
are
not
necessarily
edge
specific.
I
mean
I
have
talked
a
lot
about
edge
in
the
presentation,
but
data
center
and
cloud
are
relevant
here
as
well.
It's
it's
just
that
in
the
edge
we
find
that
these
use
cases
are
particularly
poorly
catered
for
due
to
the
amount
of
fragmentation
so
really.
B
So
it's
agnostically
referring
to
the
need
to
run
more
than
one
workload
it
does.
It
doesn't
specify
necessarily
full
stack,
virtualization
or
containerization.
It's
really
just.
There
is
a
need
for
multiple
applications
that
are
resident
on
a
node
and
are
distinct
from
each
other
to
be
able
to
consume
parsec
and
the
secure
services
behind
it.
B
B
We've
said:
that's
a
c
language
interface.
It
was
designed
for
embedded
programming
on
end
points,
so
what
parsec
does
is?
It
brings
psa
crypto
into
the
application
class
world,
this
more
rich
compute
world
by
creating
a
service
around
the
crypto
api.
So
this
is
a
software
service.
It
represents
and
controls
access
to
the
underlying
platform,
hardware
and
being
a
service.
It
needs
a
way
to
be
called
by
applications.
B
We
do
this
by
defining
an
inter-process
communication
or
ipc
layer
with
a
wire
protocol
that
defines
the
inputs
and
outputs
of
each
operation
and
the
derivation
from
psa
crypto
on
this
protocol
is
a
close
one.
There
is
pretty
much
a
one-to-one
mapping
between
contracts
in
this
ipc
interface
and
the
operations
of
the
psa
crypto
api.
B
The
only
difference
actually
is
that
this
protocol
is
now
language
agnostic.
The
the
final
piece
is
an
ecosystem
of
client
libraries
in
popular
programming
languages,
and
these
are
designed
to
create
a
developer
friendly
experience,
putting
the
crypto
services
directly
to
the
fingertips
of
application
developers,
and
this
is
what
parsep
really
is
conceptually.
This
onion
skin
set
up
layers,
decoupling
the
workload
from
the
platform.
B
So
imagine
that
everything
you
see
here
is
running
on
an
infrastructure
or
edge
node
supported
by
a
rich
os
linux,
for
instance.
So
here
you
can
see
the
parsec
service,
which
represents
the
underlying
hardware
and
acts
as
a
broker
for
access
to
it.
The
parsec
service
is
written
in
rust.
We
felt
that
rust
was
occupying
just
the
right
space
for
us
in
terms
of
having
predictable
performance
coupled
with
lots
of
safety
and
security
characteristics.
B
B
B
B
B
So
what
they
consume
instead
is
a
client
library
and
the
idea
behind
parsec
is
we
create
a
whole
ecosystem
of
these
client
libraries,
which
grows
over
time
to
support
popular
languages,
but
we
don't
want
these
client
libraries
to
be
clunky
language
bindings
on
the
wire
protocol,
and
this
really
is
one
of
the
defining
characteristics
of
the
consumption
side
story
with
parsec.
We
want
each
client
library
to
be
designed
and
developed
to
provide
a
very
fluent
natural,
idiomatic
programming
experience
that
is
tailored
to
that
language.
B
So
it
will
be
attractive.
It
will
feel
natural
to
developers
in
that
language,
and
one
of
the
ways
in
which
we
aim
to
achieve
this
is
by
structuring
the
client
libraries
into
different
layers
of
abstraction.
The
full
psa
crypto
api
will
always
be
accessible,
along
with
all
of
its
different
settings,
for
controls
of
things
like
algorithm
choice,
key
size
or
key
usage
policy,
so
that
full
programming
service
will
always
be
there.
When
you.
E
B
B
B
And
here's
a
visual
representation
of
that
layering
concept.
So
you
can
see
here
we
we
can
choose
to
code
at
a
relatively
low
level
of
abstraction,
so
quite
close
to
the
wire
protocol
primitives
themselves.
If
we
need
that
degree
of
sophistication
and
granular
control-
or
we
can
make
use
of
this
simplified
experience
where
the
client
library
is
making
some
choices
for
us
based
on
maybe
configuration
data
that
is
automatically
picked
up
from
the
service.
B
B
Cases,
okay,
so
all
of
that
was
about
parsec
as
an
api.
We've
talked
about
it
as
an
abstraction
layer.
So
let's
talk
now
about
parsec
as
a
brokering
layer,
as
the
provider
of
secure
services
in
this
multi-tenant
or
multi-application
environment,
and
the
challenge
is
twofold
here.
So
the
first
is
we
have
this
contention
for
resources.
B
The
second
is
that
there
must
be
clear
differentiation
between
those
multiple
workloads,
because
there's
a
need
for
separation
of
secure
assets
such
as
keys
each
workload
needs
some
kind
of
unique
and
persistent
identity
and
that
identity
has
to
come
from
somewhere.
There
has
to
be
a
component
of
the
overall
system
that
understands
where
the
workloads
came
from
that's
able
to
vouch
for
their
provenance
and
for
their
identity
in
a
way
that
past
tech
can
trust.
B
B
Now
the
role
of
parsec
here
is
actually
not
to
decide
that
identity
or
to
assign
it,
but
just
to
honor
it.
So
it
has
to
treat
each
incoming
api
call
as
coming
from
a
workload
with
a
known
identity,
and
it
must
partition
key
stores
and
broker
the
access
to
the
hardware
based
on
that
identity.
So
we
don't
want
workload
a
to
be
able
to
operate
with
keys
that
were
created
by
workload
b,
for
instance,.
B
Now,
where
does
the
identity
come
from
and
the
answer
to
that
really
depends
on
the
deployment.
So
again,
this
is
one
of
those
areas
where
parsec
doesn't
prescribe
a
single
answer.
It
could
be
a
container
manager
or
an
orchestrator.
For
example,
we
just
refer
to
it
opaquery
as
an
identity
provider
for
parsec
to
work
in
a
multi-tenant
environment.
B
However,
whatever
the
identity
provider
happens
to
be
on
any
given
system,
we
do
know
that
parsec
has
to
be
able
to
trust
it.
So
there's
got
to
be
a
trust
relationship
between
the
parsec
service
and
the
identity
provider
on
that
box,
which
would
be
based
on
something
like
pki
or
certificate
sharing.
B
B
B
And
what
does
parsec
do
with
the
token?
Well
uses
it
as
a
partitioning
primitive,
so
based
on
that
identity,
whatever
it
is,
it
makes
decisions
about
how
to
grant
access
to
keys,
for
instance,
and
it
can
trust
those
tokens
because
they
will
have
been
signed
by
the
identity
provider
and
parsec
is
able
to
validate
that
signature
according
to
a
shared
trust.
Bundle
that
resides
between
the
two
components.
B
Okay,
so
with
that,
we've
covered
the
the
sort
of
dual
roles
of
parsec
as
being
a
common
abstraction
layer
and
as
a
broker
and
mediator
of
services.
So
these
really
are
the
two
things
that
are
critical
to
enabling
a
cloud-native
style
of
workload.
Delivery
onto
these,
otherwise
very
diverse
and
fragmented
edge
platforms.
B
So
we
can
summarize
the
value
proposition
really
of
parsec.
It's
these
four
things:
it's
abstraction
common
api,
truly
agnostic
based
on
modern
cryptographic,
principles,
mediation,
security
as
a
microservice
brokering,
access
to
the
hardware,
providing
isolated,
key
stores
in
a
multi-tenant
environment
ergonomics,
which
is
how
we
refer
to
this
client
library.
Ecosystem,
brings
the
api
right
to
the
fingertips
of
developers
in
any
language.
B
The
mantra
is
easy
to
consume
hard
to
get
wrong
with
security.
That's
what
we
want,
and,
lastly,
openness.
It's
an
open
source
project,
inviting
contributions
to
enhance
the
ecosystem,
both
within
the
service
and
among
those
client,
libraries
and
you
might
have
realized.
Just
from
hearing
me
talk
that
there
are
lots
of
degrees
of
freedom
and
axes
on
which
to
grow
parsec
as
an
ecosystem.
It
really
is
an
ecosystem
project.
B
B
B
But
then
we
have
orchestration
systems
such
as
kubernetes
that
are
actively
managing
the
execution
of
the
workloads
projects
such
as
spiffy's
fire,
as
I
mentioned
concerned,
with
identity,
and
it's
also
interesting
to
think
of
how
per
second
notary
could
potentially
fit
together.
When
we
think
about
the
general
problem
of
running
trusted,
workloads
on
secure
platforms.
B
Right,
let
me
do
a
project
status,
so
just
a
few
quick
slides
on
the
status
of
the
project
as
it
exists.
Today
it's
been
public
in
github
since
october
last
year.
It's
all
apache2
licensed
the
available
api
so
far
is
what's
targeted
at
supporting
the
portable
root
of
trust
use
cases.
So
that's
provisioning,
key
pairs
exporting
the
public
key
signing
with
the
private
key.
B
B
B
We
have
a
tpm
2.0
back
end
as
well.
Supporting
those
same
primitives
and
the
main
engineering
focus
right
now
is
to
look
at
ways
of
getting
those
existing
pieces
into
production
systems.
So
arm
is
looking,
for
example,
using
the
parsec
technology
internally.
We're
doing
some
product
integrations,
as
are
some
other
organizations.
B
The
client
library
so
far
has
been
part.
The
client
library
story.
Sorry
so
far.
It
has
really
been
about
prototyping
and
sketching
to
examine
what
the
model
should
be
for
client
libraries,
but
also
to
build
those
pieces
that
are
vitally
needed
for
short-term
integration
plans.
So
right
now,
our
team
in
arm,
for
instance,
we're
doing
some
client-side
work
with
rust
and
with
a
c
callable
wrapper.
B
B
B
B
As
I
said
at
the
start,
the
initial
seeding
of
this
project
was
a
collaboration
across
docker
and
arm,
and
this
was
prior
to
the
point
where
dhaka
was
partly
split
out
into
mirantis,
so
we
now
have
those
three
organizations
that
have
been
responsible
for
the
content
of
the
project.
So
far,
I'm
very
active.
Currently,
we
are,
is
very
active.
Currently
we're
expecting
also
some
contributions
to
start
flowing
in
from
lenaro
as
well.
B
At
some
point
in
the
near
future,
we
have
potential
industry
partner
adoptions
in
flight,
actually
more
than
shown
here,
but
some
of
them
are
in
the
very
early
stages
and
it's
not
possible
to
talk
about
them
publicly.
Just
yet
open
governance
for
this
project
is,
is
really
going
to
open
more
doors.
We
think
in
terms
of
these
partnerships
and
contributions,
and
indeed
in
some
cases,
we've
found
that
open
governance
is
effectively
a
gate
to
adoption
for
some
organizations
as
well.
B
You
can
see
the
github
reference
there
don't
be
confused
by
the
name
parallax.
Second,
the
project
has
multiple
github,
repos
and
they're
all
collected
together
into
an
org.
Ideally,
the
orb
would
have
been
called
parsec,
but
the
last
that
was
taken
already
so
we've
had
to
use
the
expanded
astronomical
term.
Instead
and
again,
there
is
that
book
repo.
There
is
a
wealth
of
additional
projects
documentation
there.
B
There
is
a
public
parsec
slack
channel
on
the
docker
community
slack
and
also
a
zoom
call
that
takes
place
every
alternate
tuesday,
which
anyone
is
free
to
join,
and
you
can
find
details
for
that
in
the
github
repo,
including
the
zoom
link
and
a
calendar
link,
so
I'll
leave
that
slide
up,
and
I
guess
we
can
end
the
presentation
at
that
point.
So
thank
you
very
much
for
listening.
Brandon
can
I
hand
back
to
you
as
chair?
Perhaps
we
can
we
can
do
questions.
C
B
B
B
So
I
think
I'm
trying
to
draw
the
distinction
between
whether
you
know
how
parsec
is
there
at
all
as
a
as
a
library
or
whether
you
know
what
kind
of
facilities
are
available
behind
it,
given
that
it
is
an
abstraction
layer
is,
is
the
question
more
aimed
at
the
first
order?
The
second
of
those
two
cases.
B
H
Let's
say
that
I
have
some
services
that
I'd
like
to
deploy
at
the
edge,
and
then
I
and
then
my
use
case
is
I
I'd
like
to
extract
some
secrets,
given
all
the
other
capabilities
with
the
integration
of
the
idp.
How
do
I
discover
that
those
that
that
parsec
is
available
as
a
service
for
me
to
leverage
to
obtain
keys,
for
example,
I
mean
ordered?
Is
that
like?
Is
there
like
a
handshake?
How
do
I
know?
Does
that
make
sense.
B
Yeah
sure
it
does
so
so
so.
The
first
thing
is
that
if
you
have
an
aspiration
to
use
parsec,
then
the
first
thing
you
would
do
is
you
would
link
with
a
client
library
now,
of
course,
that
doesn't
necessarily
mean
that
parsec
is
definitely
going
to
be
on
your
system,
but
but
there
is
a
handshake
stage
and
actually
the
handshake
stage
is
capable
of
doing
a
couple
of
things
right.
It's
capable
of
determining
whether
passtech
is
there
at
all
it's.
B
Again,
there
is
a
difference
between
the
design
and
what
is
available
in
the
project
today.
So
some
of
those
negotiation
pieces
are
kind
of
at
an
early
stage.
They
haven't
all
been
implemented,
haven't
all
been
built,
but
the
vision
really
with
parsec
is
that
it
is
an
abstraction
right,
so
you
shouldn't
have
to
care
and
the
client
library
is
going
to
be
responsible
for
making
some
of
those
handshake
api
calls
to
do
things
like
smart
defaulting.
B
C
I
I
B
Right,
okay,
so
so
so
so,
the
first
testing
framework
is
really
it's.
It's
based
on
a
subtest
kind
of
principle.
So
the
idea
is
that
you
have
a
server
on
which
you
run
the
parsec
service,
and
you
run
the
first
test
suite
which
then
just
soak
tests
against
the
service
over
a
long
period
of
time
with
with
various
randomization
techniques.
G
Hi
guys,
I'm
janet,
I'm
one
of
the
devil
players
on
on
the
president
project
actually
works
on
the
on
the
first
testing
framework,
so
yeah,
it's
it's
using
lip
fuzzer
and
it
essentially
generates
generates
bytes
by
streams
that
it
feeds
into
the
let's.
Let's
enter
the
input
of
of
parsec,
so
it's
essentially
like
simulating
an
input
from
the
from
the
domain
socket
m4
and
yeah
in
a
form
of
of
bytes
received.
G
B
Thanks
jonat,
I
will
just
clarify
so
on
the
point
with
the
golang
client.
So
there
is
a
repo
there's,
a
repo
in
the
parsec
org
for
a
golang
client.
It's
it's
effectively
at
a
prototyping
stage.
It's
the
first
client
that
we
created,
but
we
created
it
with
the
vision
to
kind
of
play
with
code
sketches
to
to
to
imagine
what
it
would
be
like
to
consume
parsec
into
golang.
It's
not
actually
a
fully
functioning
client
at
the
moment.
B
B
Currently
white,
there
isn't
a
parsec
white
paper
currently
so
so
arm's
contribution
to
parsec
is
under
a
under
a
project
called
cassini,
for
which
there
there
is
a
white
white
paper
that
that's
to
do
with
the
general
problem
of
cloud
native
practices
at
the
edge.
So
so
I'd
say,
go
go!
Have
a
look!
Look
at
the
book
resource!
Look
at
cassini
if
you're
interested,
as
I
say
that
that's
that's
an
arm
thing.
B
C
With
pasta,
kind
of
like
hiding
the
abstraction
of
the
hardware,
so
usually
when
I
think
about
accessing
services
from
the
hardware
modules,
there
is
a
step
which
I'm
able
to
verify
that
the
what
I'm
talking
to
actually
resize
in
hardware
is
there
a
contract
between
the
client
and
parsec?
Where
does
pass
extend
as
like?
Is
it
crucial
to
as
part
of
the
tcp
or?
What's
the
the
the
trap
view
in
that
case,.
B
Yeah,
so
the
the
ability
to
attest
to
key
residents
in
hardware
is
it's
it's
not
in
the
interface
today,
but
it
is
design
roadmap.
So
we
we
know
there
is
going
to
be
a
need
in
a
wider
deployment
for
an
application
to
to
be
able
to
attest
that
a
key
is
hardware
protected
and
not
exportable,
but
we
we
don't
have
it
in
in
the
api.
B
B
B
A
A
A
What
one
example
that
we
had
and
was
really
useful
is
that
when
we
started
building
the
service-
and
at
the
moment
we
we
switched
from
a
single
threaded
to
multi-threaded
application,
everything
just
worked
and
we
we
didn't
have
any
any
safety
issues,
any
data
that
was
written
at
the
same
time
with
a
concurrency
problems.
Everything
just
worked
so
easily
and
it
was
there
really
great
to
to
to
see
that
the
the
other
big,
the
the
other
face
of
the
coin.
A
The
the
fact
that
rust
projects
with
the
cargo
package
manager
are
really
standardized
makes
it
really
easy
to
to
build
a
test
infrastructure
to
add
the
integration
test
unit
test
to
to
the
project,
easy
to
to
publish
your
crates
for
everybody,
to
use
easy
to
have
a
free
online
documentation,
so
yeah,
so
the
yeah,
the
the
big
two
parts
that
were
really
helpful
to
us
was
the
the
safety
features
and
the
infrastructure.
I
think
yeah.
A
A
There
is
definitely
a
need
in
hold
the
company
to
to
add
more
security
in
our
projects.
So,
yes,
when,
whenever
you
think
about
a
secure
development,
rust
is
automatically
one
of
the
the
possible
ocean,
and
since
since
we
are
building
building
per
second
on
top
of
an
operating
system
on
a
on
a
known
target,
there
wasn't
much
risks
to
to
to
use
a
language
that
was
quite
new.
B
Yes,
it's
a
it's
a
it's
a
play
on
intercepting
the
future.
So
so
when
we
were,
when
we
were
looking
around
for
the
right
language
to
write
the
parsec
service
in,
we
knew
that
parsec
was
going
to
be
a
systems,
programming
piece
and
we
knew
that
security
safety
memory.
Safety
in
particular
was
was
going
to
be
paramount.
B
Rust
just
announced
itself
really
as
being
as
being
the
right
choice.
Now,
it's
not
you
know
it's
still
a
relatively
young
language,
but
playing
like
playing
the
long
game
with
it.
It
seems
to
be
going
in
the
right
direction.
The
barrier
to
entry
can
be
a
little
higher
than
other
programming
languages,
but
I
think
that's
you
know
you.
You
pay
the
pain
at
the
right
point.
E
That
there's
a
lot
of
industry
adoption
within,
I
would
say,
open
source
adoption
of
rust
and
secure
projects.
A
lot
of
the
blog
and
lenaro
trusted
apps
and
trusted
firmware
trusted
apps
that
go
into
office
are
written
in
rest
and
more
and
more
sections
of
some
of
the
secure
firmware
are
going
into.
C
C
C
B
I
see
so
you're
you're
thinking
of
a
use
case
where
parsec
is
effectively
protecting
your
master
key
to
what
is
otherwise
a
a
software
managed
key
store,
yeah
yeah.
I
I
certainly
that's
a
use
case
we're
looking
at
I.
So
what
volt
integration
is
something
it
integration
specifically
with
volt
is
is
is
something
that
I'd
like
to
see
investigated,
but
also
the
use
of
parseca
to
protect
the
master
key
for
a
system.
C
B
It
could
depend
on
the
framework.
I
think
volta
volt
in
particular,
is
is
kind
of
interesting
right
because
it
has
volt.
Vault
has
key
management
storage
plug-ins
into
which
we
could
potentially
plumb
parsec,
so
in
which
case
parsec
would
then
be
kind
of
part
of
the
part
of
the
vault
infrastructure
if
you
like,
but
but
all
of
these
things
are
things
that
would
have
to
be
investigated.
C
F
The
time
for
samba
well,
we
are
currently
reworking
the
sandbox
process,
hopefully
where
it
should
become
quicker
it
in
principle.
It
doesn't
take
very
long
at
all,
but
in
practice
we've
been
it's
been
very
variable
and
I'd
say
between
one
and
three
months,
but
we're
hoping
to
kind
of
cut
it
down.
So
there's
a
fixed
schedule
at
which
sandbox
projects
get
accepted.