►
From YouTube: Working Group: 2020-11-05
Description
* CA Certificates
* Stack Buildpacks
A
A
A
Yeah,
I
mean
that's
true,
but
I
also
feel
like
a
lot
of
those
things
that
are
better
bash
tend
to
be
like
side
effects
as
a
service
like
we
struggled
that
with
that
in
the
build
pack
too,
where
it's
like.
How
do
I?
How
do
I
test
this
aside
from
just
running
maven,
you
know-
and
so
I
don't
know-
sometimes
it's
just
a
hard
problem.
I
guess
that's.
That's
a
that's
a
good
phrasing
side
effects
as
a
service.
I
like
that.
C
Which
we
think
is
somewhat
related,
we'll
just
talk
about
ca
certificates,
so
we
think
we've
come
up.
I
mentioned
this
at
the
other
working
group
with
the
solution
like
we
wrote
a
build
pack
that
can
install
ca
certificates
that
build
and
run
time
that
doesn't
need
root,
privileges
and
well.
This
is
a
paquetto
build
pack.
C
We
wrote,
I
think,
it's
relevant
to
the
group,
because
there
are
if
the
ca
certificates
are
not
an
important
use
case
for
stack
packs
out
of
the
gate
I
feel
like
they
introduce
certain
types
of
complexity
that
could
be
cut
out
for
later.
So
things
like
you,
don't
like
even
recovering
the
entire
build
plan
right,
if
the
only
thing
we
were
doing
was
mixins
in
the
stack
pack,
all
you
need
is
the
delta
of
mixins
to
rerun
something
during
rebase
and
things
like
providing
that
platform
directory
during
rebase
and
stuff,
like
that.
B
B
You
know
in
many
cases
can
use
them,
but
we
did
some
experiments
with
those
like,
admittedly,
quite
a
long
time
ago,
and
found
that
a
lot
of
things
don't
or
at
least
a
couple
things
we
saw
it
didn't
respect
them
to
the
point
where
it
you
know
like,
for
whatever
reason
we
put
that
down
and
said
it's
important
that
we'd
be
able
to
install
c
asserts
in
the
oligarch
store.
I
haven't
seen
anything
that
doesn't
work
with
it
now
and
so
it's
like
I'm
not
saying.
I
think
this
isn't
a
solution
that
is
complete.
B
I'm
just
saying
I
worry
that
it's
you
know
it
feels
early
to
say.
Oh,
we
solve
the
problem
and
then
you
know
skip
adding
support
for
it.
When
you
know
there
are
probably
things
there,
there
may
be
things
that
you
know:
may
look
for
ca.
Certs
directly.
A
lot
of
different
languages
have
language
modules,
for
instance,
that
parsee
search
directly
and
don't
use
openssl.
A
Yeah
but
like
those
are
incredibly
rare
to
like
none
of
the
languages
that
we
that
the
people
on
this
call
actually
care
about
java
would
be
the
big
exception,
and
it
turns
out
that
writing
the
shim
to
link
java
to
these
same
environment
variables
is
trivial
to
do,
and
so
like
one
of
the
things
that
has
bugged
me.
Obviously
I
it
has
bugged
me
so
much.
I
came
to
the
thursday
meeting
so
like
take
this
as
an
indication
of
how
I
feel
about
this.
A
Is
that
because
we
so
tightly
tied
this
and
like
this
is
sort
of
a
broader
thing
that
I
want
us
to
think
about.
We
needed
a
surgical
fix
nine
months
ago.
Support
for
cia
starts
to
build
and
run
time,
but
because
we
tied
it
to
something
like
stack
packs
that
would
take
so
long
to
land
and
we
added
additional
complexity
to
stack
packs,
making
it
harder
to
land
that,
like
we,
we
missed
the
point
like
I
really.
A
If
we,
if
we
hadn't
sort
of
tied
it
would
emily,
have
noticed
these
environment
variables
six
months
ago,
and
we
would
have
had
it
this
whole
time.
Like
that's.
The
key
thing
is,
we
can
deliver
for
the
vast
majority
of
users.
The
functionality
they've
actually
been
looking
for
in
this
way,
and
until
someone
comes
to
us
and
says,
hey,
I'm
running
r
and
this
doesn't
work
but,
except
I'm
pretty
sure
r
does
do
this
like
why?
Why
did
it
have
to
be
more
complex
than
this.
C
A
A
So
I
actually
feel
like
I
was
saying
that
we
could
probably
pull
off
c
certs
without
stack
packs
a
while
ago,
so
I'm
very
much
support
trying
to
to
find
a
way.
I
also
think
it's
really
healthy
to
have
multiple
solutions
to
this
problem,
especially
like,
even
if
we
think
there's
like
edge
cases
for
a
particular
solution.
A
Eventually
delivering
stack
packs,
as
a
more
blanket
solution
seems
seems
totally
fine
and
if
maybe
maybe
not
even
just
fine
but
fantastic
right,
like
a
stack
that
does
not
want
to
support
stack,
build
packs
might
would
need
an
alternative
solution,
so
I
mean
like
direction.
It's
going.
Is
all
I'm
saying.
E
A
C
E
We're
talking
about
right
now,
right
like
when
we
have
the
ca,
cert
single
file
versus
all
the
different
hashed
sim
links
essentially
and
how
that
works
with
the
docker
vm,
and
I
created
a
blog
post,
which
you
know
never
really
posted,
because
it
essentially
the
the
ground
slightly
kept
moving
from
time
to
time,
and
it
seemed
like
you,
it
didn't
satisfy
still
a
hundred
percent
of
the
cases
right.
So
all
that
seemed
like
patchwork,
not
so
much
something
that
was
a
robust
implementation.
E
C
Yeah,
so
I
think
the
impression
we
were
under
before
was
that
you
know
how,
in
the
vm
there's
like
a
directory
with
a
bunch
of
certs
and
a
bunch
of
hash,
sim
link
pointing
at
the
certs
and
there's
also
one
giant
cert
file.
I
think
we
were
under
the
person.
We
would
have
to
update
the
giant
cert
file
with
our
shirt
to
make
everything
work,
but
it
seems
like
there
are
two
ways
to
configure
openssl
and
a
variety
of
other
tools
with
different
crypto
libraries.
C
They
all
seem
to
support
these
environment
variables
where
you
can
set
both
the
cert
file
and
the
search
directory,
and
not
only
that,
but
the
start
directory
can
be
sort
of
a
a
bunch
of
path,
locations,
sort
of
like
a
path
environment
variable.
So
a
build
pack
could
at
build
time
and
also
at
run
time,
just
create
one
additional
location
for
certs
and
append
this
directory
to
the
ssl
certs,
searcher
environment
variable
and
then
the
search
will
be
respected
by
all
the
tools.
E
A
A
C
E
And
it
sounds
like
that
this,
if
we're
talking
about
it
as
a
build
pack,
is
a
very
independent
solution
that
isn't,
you
know
attached
to
anything
at
all
right
like
it's,
not
even
a
pack
implementation,
necessarily,
it's
just
pocatello
releases,
something
that
does
this
thing.
The
heroku
builder
includes
the
same
sort
of
build
pack
or
their
implementation
of
it.
C
Yeah
exactly
so,
I
can
show
you
how
this
works.
Now.
We've
made
a
decision
that
at
run
time
we're
still
supplying
the
shirts
at
the
last
minute
with
a
binding,
but
this
would
work
just
as
well
if
you
baked
them
in
at
build
time,
so
I've
created
some.
I
have
a
server
running
that
requires
a
ca
that
I've
signed
to
connect
to,
and
I
have
some
sample
applications
here.
Let's
do
go
on
here
for
a
second,
so
I'm
going
to
build
this
sample.
Sorry,
I
forgot
to
change
the
path.
C
Okay,
so
I'm
building
a
go
application.
All
it
does
is
basically
accepts
a
single
positional
argument
and
curls
that
end
point,
so
this
first
example
isn't
using
ca
search
at
build
time.
It's
a
runtime
example,
but
we
could
do
a
build
time.
Example
as
well,
and
what
the
ca
cert
bill
pack
does
is.
It
contributes
a
helper
that,
like
a
profile
d
helper,
but
eventually,
could
be
an
exact
d
helper
once
we
support
that.
That
will
then
look
for
a
ca,
cert
binding
and
install
add
the
trusted
search
at
runtime.
C
C
A
build
time
example
had
to
be
a
little
bit
more
contrived
because
I
was
too
lazy
to
like
create
an
actual
build
time
dependency.
That
was,
you
know
like
a
node
module
server
on
my
custom
endpoint
here,
but
I
have
a
build
pack
that
just
tries
to
curl
something
at
build
time.
So
let's
say
I
was
going
to
build
this
node
application.
C
C
C
C
B
D
E
D
E
D
C
C
B
B
A
A
C
Only
solution
reduces
some
complexity,
because
you
don't
need
to
necessarily
have
platform
available
at
rebase
time.
You
don't
need
the
full
build
plan
available
at
replace
time.
You
could
just
use
sort
of
the
diff
of
mixins
between
the
run
image
and
the
app
image,
and
I'm
wondering
if,
by
cutting
out
a
more
complicated
use
case,
that
we're
trying
to
support
on
the
first
pass
would
give
us
a
vertical
slice
to
be
easier
to
move
forward
on.
D
C
I
think
we
don't
need
to
worry
about
storing
the
entire
build
plan,
and
especially
if
that
build
plan
includes
like
let's
say
we
installed
ca,
search
the
first
time
and
then
you're
redoing
them
the
second
time
like.
Maybe
that
plan
had
paths
to
search
in
it
and
those
paths
are
actually
different
when
you're
running
on
rebase,
because
they
weren't
baked
into
the
image
they're
provided
in
arbitrary
binding
or
something
like
that.
C
A
I
mean
it
is
simpler.
I
would
worry
that
it's
too
simple
part
of
the
reason
that
we
went
the
direction
of
having
a
more
generic
mechanism
than
like
the
original,
like
figure
it
was
like,
extend
binary
or
something
that
would
run
on
the
builder.
You
know
the
the
thing
that
stephen
originally
proposed.
Part
of
the
reason
we
went
with
a
more
generic
solution
was
like
the
conversations
we
had
with.
A
I
can't
remember,
if
I
can
say
or
not,
but
like
two
companies
that
I
think
that
were
pretty
well
known,
that
we
both
talked
to
that
had
teams
maintaining
base
images
that
wanted
to
provide
like
custom
binaries
that
various
teams
in
their
organization
could
have
installed
like.
I
can't
remember
some
specific
examples,
but
it
was
basically
like
yeah.
A
We
have
this
like
security
scanning
binary
that
needs
to
be
installed
with
root
privileges,
but
they
want
the
like
app
developer
to
opt
in,
and
so
the
ca
cert
build
pack
example
that
was
in
my
rfc
is
kind
of
meant
to
be,
like
a
more
like
a
to
illustrate
that
kind
of
thing
where
you
have
it's,
not
a
mix-in
and
you
have
like
a
build
pack
that
triggers
the
stack
pack.
So
I
kind
of
feel
like
that's
still
an
important
enough
use
case,
that
we
should
try
to
incorporate
it.
A
C
Yeah,
I
guess
I
was
hoping
that
we
were
in
a
sweet
spot
where
we
had
gone
far
enough
down
the
path
of
what
it
would
look
like
to
add
those
things
later
that
we
know
our
solution
doesn't
preclude
it,
but
it
would
allow
us
to
ship
something
much
simpler
by
cutting
it
down
right.
That's
that's
the
proposition.
I
guess.
B
Getting
the
rfc
approved
with
the
more
general
build
plan.
Functionality,
though,
doesn't
prevent
us
from
shipping
the
mixing
part
and
speculation
part
before
the
other
parts.
Respect
right.
I
worry
that
if
we
like
had
built
a
bunch
of
abstraction
in
the
current
rfc
that
was
just
intended
for
ca
starts
and
was
clearly
really
specific
to
that
use
case,
and
we
discovered
that
we
can
probably
push
off
the
per
app.
B
You
know
installing
stuff
into
the
os
search
store,
proper
problem
for
longer,
because
it's
like
not
as
big
of
a
problem
for
a
lot
of
types
of
apps
I'd,
be
supportive
of
cutting
that
see
a
certain
specific
functionality
out,
but
I
don't
see
a
lot
of
stuff
in
the
current
rfc
that
looks
like
it
was
just
designed
for
ca.
Certs
to
me.
That
was
just
kind
of
like
an
example
of
a
type
of
change.
B
It's
not
a
package
change
and
the
thing
we
designed
to
support
it
is
like
generic
way
of
representing
you
know
things
that
can
be
provided
on
the
base
image
that
other
build
packs
can
can
require
and
not
like
something,
that's
very
tailored
for
ca
sorts,
but
it
could
be
wrong.
It
might
be
really
tailored
for
c.
Certainly
just
you
know,.
D
D
D
B
C
C
E
D
Yeah,
I'd
like
to
see
an
example
that
uses
like
you
know
requires
provides
with
metadata
that
isn't
ca
certs
as
well
like
a
real
world
sort
of
example.
That
would
be
nice
to
have
because
yeah
persisting.
The
build
plans,
definitely
complexity,
that
we
that
we
wouldn't
have
to
take
on
if
we
didn't
have,
if
we
didn't
have
to
that'd
be
kind
of
nice
but
yeah.
If
we
don't,
if
we
don't
mount
the
platform
during
rebase,
but
we
do
it
during
build
that
sort
of.
D
C
D
C
A
B
C
C
A
B
I
have
a
alternative,
which
is,
we
could
provide
the
platform,
different,
build
and
extend,
and
then
we
could
just
store
the
environment
variables
that
we
set
or
like
that
were
you
know,
set
in
the
image
somewhere
and
then
on.
Rebase
recover
those
same
environment
variables,
because
we
don't
actually
want
to
change
the
environment
variables
on
rebates
anyways.
We
want
them
to
be
the
same
values.
They
were
originally
because
it's
a
rebase,
so
I
don't
think
we
actually
want
the
platform
to
run
rebase.
B
I
think
we
want
the
old
platform
der
from
the
extend
phase
as
it
was
when
that
extent
happened
when
rebates
was
played,
so
I
actually
I
don't
know
if
this
is
the
same
problem,
we
think
it
is,
I
think
it
may
just
be.
We
need
to
store
the
values
of
the
environment
variables
that
got
set
during
extend
and
recover
them
in
the
environment
potentially
and
rebase.
I
think
that
could
get.
D
Really
weird,
if
you
have
secrets
like
artifactory
and
stuff
like
those
need
to
rotate,
maybe
you
set
them
in
your
platform,
and
you
know
you
rebase,
a
year
later,
your
artifactory
credentials
that
are
stored
at
the
platform
level.
Those
those
do
have
to
rotate
and
stuff
like
that,
but
it'll
be
a
different.
C
Theoretically,
a
platform,
that's
putting
things
in
a
binding
might
be
surprised
that
they
end
up
then
hardcoded
into
the
image
like
you'd
want
to
be
very
careful
about
telling
people
that,
like
the
environment
variables
in
the
platform
directory,
are
treated
very
differently
than
the
bindings
like.
What
is
what
isn't
secret.
B
B
E
A
Good
plan,
I
mean
that's,
that's
sort
of
the
proposal
with
the
cacered
example
is
something
like
a
secondary
build
pack
would
maybe
we
should
get
into
the
rc,
but
the
the
example.
That's
in
the
rc
is
a
sort
of
secondary
user
space.
Build
pack
requires
ca,
cert
and
then
in
the
metadata
can
provide
like
the
path
to
the
cert
or
the
actual
cert.
A
A
A
B
I
was
going
to
ask
from
what
we
have
now.
What
are
the
things
that
people
feel
they
would
have
to
change
in
order
to
get
this
approved,
and
the
one
thing
that
I
can
identify
so
far
is
we
need
to
make
some
decision
on
environment
variables
right,
but
does
anybody
feel
like
we
need
to
cut
the
build
plan,
entry
that
they're
uncomfortable
with
the
non-mix
and
build
plan
entries,
or
should
we
keep
that
in
for
now.
B
B
A
B
B
E
C
A
Well
for
well
for
one,
I
think
it
just
it's
one
less
thing
people
need
to
think
about
if
they're
offering
a
stack
pack,
the
other
is,
it
gives
us
a
little
wiggle
room
in
the
future.
To
use
a
stack
platform
directory
is
a
thing
instead
of
having
to
like
figure
out
what
to
do
with
it
later
like.
If
we
run
into
a
situation
where
we
we
need
something
specific
to
stack
packs
that
could
be
provided
in
that
way,
and
I
don't
have
an
example,
but.
B
B
Well,
I
mean
actually
in
the
case
of
platformer,
it's
the
last
directory
and
so
there's
no,
you
know,
enforcement
of
the
you
know
positional
arguments
you're
passing
into
a
script,
so
it
doesn't
really
matter.
It's
like
the
question
is:
should
we
tell
buildtech
authors
that
they
can
rely
on
rv,
3
or
whatever
existing
in
stack.
B
A
D
B
E
E
D
D
B
A
But
there's
plenty
of
ways
for
rebates
to
be
different,
depending
on
when
and
where
you
ran
it,
whether
it's
a
url
that
the
artifact
at
the
other
end
changed
or
some
other
thing,
and
this
is
at
least
one
that
is
determined
by
the
person
running
the
rebase
operation.
Rather
than
the
stackpack
author.
B
I
think
the
the
problem
is
that
stackpacks
are
just
intended
to
make
abi
compatible
changes
and
if
the
environment
were
a
separate
environment
that
were
just
intended
for
stack
packs
that
just
affected
those
backpacks
and
was
configuration,
that's
along
the
lines
of
making
those
backpacks
make
api
compatible
changes.
That
would
be
okay,
even
if
it
varied,
because
you
could
just
continue
to
stipulate.
B
B
The
problem
is
the
other
build
pack
environment
variables
anytime.
Any
build
pack
needs
environment
variables
for
configuration.
It's
always
going
to
be
different
on
rebase
right.
So,
if
you're
building
a
go
app-
and
you
say
here-
might
go
targets
on
build
you're
not
going
to
supply
those
on
rebase
and
so
now
now
backpacks
don't
work
for
all,
go
apps
right
and
for
potato
we're
moving
to
environment
variables
for
configuration
for
everything.
B
B
D
C
C
C
B
But
the
stackpack
author
is
the
same
person
who
makes
new
run
images
right
so
saying
that
is
the
same
thing
as
saying
the
person
who
makes
new
run
images
could
ship
a
new
run
image.
That's
actually
ubuntu
2004,
instead
of
1804
right
the
whole
per
the
reason
why
we
put
stackpack
in
the
domain
of
the
stack
author
is
it's
the
stack,
author's
responsibility
to
enforce
api
compatibility?
B
A
B
It's
true,
but
it
makes
the
stack
pack
backpack
author's
job
pretty
hard,
because
if
they
don't
pass
clear
end
everything
in
the
environment's
going
to
be
set
and
the
environments,
you
know
they
have
no
way
of
ensuring
that
the
environment,
or
without
going
through
some
serious
hoops
right
like
setting
that
special
flag
and
build
pack
tommle.
You
know
they're
gonna
end
up
they're,
not
gonna,
easily
be
able
to
enforce
that
the
environment
doesn't.
B
C
B
In
in
the
generic
case,
though,
right
or
in
like
the
case
that
we
care
about
for
operating
system
packages
right,
it
really
is
always
safe.
It's
going
to
be
a
tool
for
installing
you
know,
updated
versions
of
you
know:
ubuntu
1804,
lts
packages
that
have
strong
guarantees
about
their
changes
or
the
same
guarantees
that
we're
providing
for
the
run
image
right.
So
in
most
cases
we
do
it
is
safe
and
we
do
get
those
guarantees
in.
B
B
C
C
A
B
I
think
a
stackpack
is
already
supposed
to
be
that
I
think
the
pro
that
there
aren't
actually
strong
differences
between
those
two
things,
because
you
may
still
need
credentials
in
the
environment
to
reach
out
to
a
separate
repository
of
lts
1804
ubuntu
packages,
because
you're
in
an
air-gapped
environment
right
or
something
like
that.
Yeah
like
mix,
I
wouldn't
say,
mix
and
build
pecs,
don't
need
that
kind
of
configuration.
This
is
why
I
haven't
proposed
a
solution
to
this
yet
right,
and
the
other
thing
is
that
I
think
root.
Build
packs.
Really.
E
A
E
D
This
weirdly
feels
kind
of
like
docker
credential
helpers,
now
to
me
for
mixing
installation
like
it's
just
a
much
simpler
interface
when
you're
just
talking
about
mix-ins
like
they
would
know
about
platform-specific
places
to
fetch
environment
variables,
to
do
things
like
login
to
esm
repositories
to
do
its
job
that
doesn't
have
to
be
so
open-ended.
It
doesn't
have
to
be
the
platform
dir,
it
can
change,
and
I
know
it
could
still
produce
different
results,
but
I
think
I
don't
know
it
just
feels
more
tightly
controlled.
B
Maybe
we
just
need
to
introduce
this
third
set
of
environment
variables,
called
stack
environment
variables
that
can
stack
and,
and
that
has
to
be
the
same
and
then
maybe
that
comes
in
platform
m
during
stack
packs
and
just
follows
the
same
convention,
and
then
we
keep
the
area
of
the
method.
We
have
different
environment
variables
for
stacks.
E
B
E
B
D
B
A
D
C
I
should
kind
of
like
the
idea
of
putting
analyze
before
detect,
because
there
are
a
couple.
Things
would
be
nice
to
check
up
front
anyways
like
what's
the
stack
id
of
the
previous
image,
and
can
we
connect
to
everything
and
then,
if
analyze,
you
know,
could
resolve
the
run
image
reference
into
a
digest
reference,
then
you
know
you're
getting
the
same
thing
later
like
we
do
the
previous
image
and
analyze
and
then
in
export.
It
could
could
work
out
nicely.
A
A
We
went
to
these
other
sections.
This
is
where
we
finished
off
and
I'm
not
sure
if
we
were
aligned
on
how
the
build
packs
and
binary
are
provided
to
the
rebase
operation,
so
think
about
that
I'll.
Try
to
think
of
an
alternative
example
for
ca,
certs
for
for
non-mixin,
build
plan
dependencies
and
then
there's
a
few
open
questions.
Like
I
mentioned
what
happens
if
the
mix
ends
change.