►
From YouTube: Office Hours: 2021-09-02
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
All
right,
so,
let's
see
the
first
one
we
have
jason.
Do
you
wanna
speak
a
little
bit
about
the
question.
B
Yeah,
so
I've
changed
roles
slightly
at
google
and
I'm
looking
a
lot
more
into.
You
know:
build
image,
attestations
and
build
materials
and
secure
software
chain
things.
B
Okay,
so
I'm
just
sort
of
deep
diving
on
things
like
permissions
and
whatnot,
and
you
know
I
always
thought
that
in
the
bill
pack
spec,
there
was
kind
of
two
users
involved:
a
privileged
and
unprivileged
one
to
build
packs
themselves
ran
unprivileged,
but
in
looking
through
the
docks,
it
seems
to
suggest
that
the
builder
image
should
actually
be
user
like
this
is
the
thing
that
the
lifecycle
binaries
sit
inside,
that
that
it
should
run
as
the
unprivileged
user.
B
So
it
seems
like
the
whole
process
is
running
as
the
unprivileged
user
and
I'm
kind
of
wondering
is
that
right
or
is
there
a
mistake
in
the
in
the
example
builder
images
or
or
you
know,
given
you
more
info
about
that.
A
There
there's
more
or
less
an
exception
when
it
comes
to
running
in.
I
believe
it's
the
creator
where
you
have
to
run
as
a
privileged
or
root
user
right
and
in
that
particular
case,
we're
running.
If
I
remember
correctly,
it's
running
that
specifically
to
be
able
to
gain
access
to
the
docker
demon
socket
in
that
particular
use
case.
To
be
able
to
do
that.
That's
the
last
recollection
I
have,
but
that's
more
or
less.
What
I
I
understand
it
to
be.
Is
that
something
different
that
one
you're
noticing.
B
Well,
I'm
just
you
know.
The
examples
right
now
are
suggesting
that
I
I
set
the
user
to
be
this,
this
cnb
user
id,
which
means
that
the
life
cycles,
I
think,
would
run
as
that
user.
Even
if
it's
creator
or
exporter,
I'm
assuming
I
mean
I'm
assuming
exporter
and
restore
stages-
need
need
access
to
the
docker
daemon,
just
like
creator
would,
but
you
know
it
just
seems
like
this
whole
process
is
running
as
the
unprivileged
user,
which
actually
my
my
more
specific
question
is
around
report
to
tamil.
B
You
know,
like
I
feel,
like
the
life
cycle.
Binaries
should
have
permissions
to
write,
reported
tamil-
I
guess
exporter
specifically
in
creator
by
extension,
but
that
the
build
pack
should
not
you
know,
so,
I'm
trying
to
figure
out
trying
to
figure
out
what
the
right
way
to
set
up
these
users
are
like.
Like
I
understand
there
might
be
historical
stuff,
I
understand
talks
might
be
out
of
date,
so
I'm
trying
to
figure
out.
You
know
what
is
the?
What
is
the
right
way
to
set
these
things
up.
A
That's
interesting,
I
know
somebody
that
could
really
help
out
with
this
is
actually
emily.
I
think
she's
like
the
mastermind
of
permissions
when
it
comes
to
that
aspect
of
it
and
why
it's
structured
in
the
way
that
it
is
now
right.
So
she
would
have
that
context.
I
could
see
if
she's
available,
to
jump
on
the
call.
A
B
B
I
think
the
default
location
is
layers,
slash
report
to
tamil
by
default,
which
you
know.
It
then
comes
back
to
my
question.
What's
the
right
way
to
set
up
permissions
for
like
say,
layers
and
platform
so
that
you
know
build
packs,
have
access
to
write
things
that
they
need
to
write,
but
they
can't
write
into
areas
where
they
ought
not
to
like
report
to
tunnel.
A
B
I
mean
we
have
builders
today
at
google
we
have
an
open
source,
one.
We
have
one.
We
have
builders
for
app
engine.
We
have
builders
for
cloud
function.
They
all
do
this
activity
of
setting
the
user
to
be
this
unprivileged
user,
I'm
kind
of
exploring
you
know.
Why
is
it
set
that
way?
B
Doesn't
that
mean,
then
that
the
unprivileged
user
can
write
and
overwrite
and
mess
with
this
report
automobile?
And
it
just
doesn't
seem
right
to
me
so
I'm
trying
to
figure
out.
You
know
like
the
very,
very
specific
way
that
this
should
be
set
up,
so
that
there's
both
a
privileged
user.
I
think
I
believe
there
should
be
two
users.
It
should
be
the
privileged
user
and
an
unprivileged
user
involved
in
this
build.
A
Yeah,
so
I
don't
disagree
with
you
on
that,
and
I
think
that
brings
about
another
if
we're
talking
about
security
in
general
right.
I
think
that
brings
about
another
sort
of
related
rfc
in
which
certain
aspects
of
or
certain
directories,
although
the
spec
itself
says
that
you
know
it's
not
writable
by
its
current
implementation,
it
is
writable
right,
so
I
think
there's.
B
You
know
we
have
a
step
that
happens
before
our
creator
step.
I
call
it
the
shim
and
it
does
things
like
chmod
layers,
folder
and
shown
the
layers
folder
and
whatnot,
and
I
think
actually
maybe
you
wrote
a
similar
thing
for
techton
and
the
same
sort
of
script.
How
script
scripting
happens
before
where
it's
like?
B
Okay,
I
want
to
show
in
all
of
layers,
I'm
going
to
show
I'm
going
to
schmad
all
of
layers
to
this
unprivileged
user
and
and
that's
you
know
that
and
that's
what
we
do
too
and
it
works
that's
great,
but
but
I'm
again
wondering
if
that's
actually
what
we
should
be
doing.
A
So
it
I
see,
I
see
the
mess
right
like
I
understand
the
quote-unquote
mess,
but
I
guess
I'm
still
trying
to
piece
together
and
understand
if
it's.
A
B
A
A
A
B
I
think
that's
I
mean
that
sounds
interesting,
but
that's
not
really
directly
my
concern
here,
but
but
that
does
sound
interesting.
B
Right
like
I,
I
believe
that
it's
configurable,
the
spec
doesn't
say
that
report.tamil
has
to
be
in
layers
that
I
can
find
it
just
it
all
it
talks
about
is
the
format
of
it
and
I
believe
I
can
drop
it
someplace
else.
So
that's
good,
but
then
it
comes
back
to
this
question
of
well.
Is
there
really
two
users
involved
right,
because
if
I
drop
it
someplace
else,
that's
still,
you
know
it's
still
being
right
of
written
by
the
unprivileged
user.
That
means
the
bill.
Packs
can
connect
with
it.
B
So
I
still
think
there
needs
to
be
two
users
involved
in
the
overall
build.
B
A
Yeah,
I
am
curious
what
some
of
the
other
more
you
know,
security,
savvy
individuals
like
I
mentioned
emily
and
steven-
would
think
about
that,
but
I
I
definitely
see
where
you're
coming
from.
A
A
Yeah
yeah
and
again
I'll
poke
people
to
go.
Look
at
it.
It
seems
like
we're
having
a
little
bit
of
an
absence
of
maintainers
today,
so
we
just
came.
B
No
worries,
okay,
cool,
that's
all
I
have
oh
and
then
the
other
question
I
have
is
the.
I
know
there
is
a
big
rfc
from
stephen,
I
believe,
about
like
kind
of
a
fundamental
change
to
the
way.
Still
black
spec
works
around
stocks
or
dropping
stacks.
I
guess
I'm.
A
Yeah,
so
it
seems
I'm
trying
to
pull
it
up.
I
don't
know
if
I'll
get
the
unicorn
because
of
how
many
comments
we
have
but
yeah
right
now.
Looking
at
the
approvals
it
looks
like
we
have
three
core
maintainers,
plus
even
four
core
maintainers
that
are
approving
this,
and
we
essentially
just
need
one
more
to
get
this
in.
So
it's
very
likely
that
this
will
happen.
I
think
the
biggest
challenge
is
just
going
to
be.
B
B
They
they
are
really
early
in
the
morning
for
me,
but
I
think
that
I
will
try
to
come.
Yeah.
A
Yeah
I
mean
I
would
say
that
those
are
the
best
for
for
anything
spec
related
or
like
yeah,
the
rc's
part,
that's
where
everybody
does
tend
to
get
a
little
bit
more
together.
A
But
if
you
give
us
a
bit
of
a
heads
up
for
these
sort
of
conversations,
we
can
make
sure
that
we
have
the
right
people
in
this
meeting
as
well.
And
so
that's
not
a
big
deal.
Sure.
B
Okay,
great,
I
will
post
a
question
on
slack,
sounds.