►
From YouTube: Platform Sync: 2021-02-10
Description
Meeting notes: https://bit.ly/38pal2Z
A
Okay,
so
let's
see
moving
on
to
status
updates,
I
can
go
first,
since
I'm
already
talking,
my
focus
has
shifted
to
tecton,
as
most
of
you
know,
right
now,
what
I'm
working
on
is
creating
a
what's
called
a
pipeline,
so
you
could
have
a
pipeline
run,
and
this
is
more
in
line
with.
I
guess
how
an
end
user
would
really
just
hopefully
pick
up
techton
and
set
up
their
pipeline
or
this
pipeline,
where
it'll
pull
the
source
from
a
git
repository.
A
There
was
a
small
blocker
that
I
posted
an
issue
to
the
lifecycle
about
allowing
insecure
registries,
that's
more
or
less
for
local
development,
but
I
did
find
that
it
could
potentially
help
with
the
migration
from
the
currently
self-hosted
windows
runner.
To
a
more
to,
I
guess,
the
one
provided
by
github,
because
if
we
do
the
non-daemon
case
and
you
allow
for
insecure
registries,
then
we'll
have
to
worry
about.
You
know
a
whole
bunch
of
the
cert
set
up
and
all
that
stuff.
So
I
posted
that
I
did
work
around
that.
A
I
just
found
the
workaround
for
that
this
morning.
I'll
add
it
to
the
ticket
it
has
to
do
with
using
ngrok
to
do
the
tls,
the
ssl
cert
stuff
and
then
just
dropping
down
from
https
to
http
when
routing
locally,
so
all
that
works
tested.
So
I
know
I've
talked
a
lot,
but
that's
pretty
much.
All
I've
been
doing
right
now.
B
C
I've
been
working
on
the
proper
implementation
for
life
cycle
run
as
for
windows,
but
that
will
likely
have
requires
at
least
one
change
to
pack,
and
I
had
it
there
as
an
agenda
item
to
kind
of
get
you
all's
opinion
on
it.
Before
I
go
down
that
route.
The
security
model
for
windows
is
a
little
quirky,
isn't
perfectly
aligned
with
linux.
So
there's
potentially
just
a
different
platform
thing
that
has
to
happen
so
yeah.
It
would
potentially
be
something
that
all
platforms
would
have
to
do
so.
A
Cool
yep,
I
see
it
in
the
agenda.
We
could
do
that
all
right
last
call
for
status
updates
now
moving
on
to
needs
discussion
for
pack
I'll
share
that,
although
I
looked
at
it
earlier
today-
and
it
doesn't
seem
like
there's
anything
new
or
pressing-
please
correct
me
if
I'm
wrong
on
that,
and
anybody
thinks
that
there's
any
of
these
issues
that
we
need
to
discuss
today.
A
I
think
dan
just
stepped
out,
but
I
don't
know
when
the
next
pack
release
is
one
of
the
things
that
I
did
kind
of
solidify
yesterday
for
tekton
is
I'm
going
to
try
to
aim
for
monthly
releases
or
updates
to
the
tecton
catalog,
so
the
next
one
I'm
anticipating
to
have
by
the
end
of
february,
and
so
I've
set
up
the
milestones
for
that.
The
only
thing
is
because
we
have
three
resources,
two
tasks
and
one
pipeline.
A
C
C
I
think
just
for
daemon
cases,
as
I
say
that,
but
it's
most
important
for
their
and
then
it
does
a
linux
syscall
to
draw
privileges
and
to
impersonate
a
the
user.
That's
defined
inside
the
container
image
windows
can
do
almost
the
same
thing,
but
it
can't
impersonate
a
user,
that's
not
logged
in
or
it
can't
impersonate
a
user
unless
that
user
has
an
active
process
running
in
that
environment.
C
C
The
idea
is,
you
can't
impersonate
a
user
that
didn't
actively
log
in
somewhere,
so
you
can't
just
pretend
to
be
someone
who
doesn't
didn't
create
a
session,
so
the
requirement
for
platforms
then
potentially
for
windows.
Only
would
be
there
need
to
be
an
active
process
running
with
the
privileges
that
you
want
to
impersonate,
or
that
life
cycle
would
want
to
impersonate.
C
The
spike
that
I
put
together
mostly
just
takes
container
run
and
then
allows
it
to
support
optional.
Exec
processes
as
well,
so
container
run,
would
still
run
as
administrator
or
root.
But
then
you
could
choose
to
have
extra
processes
to
be
exact
by
different
users
and
that's
how
pac
would
potentially
solve
this.
It
would
start
up
a
it
would
exact
a
process
unless
it's
like
docker
exec
and
then
it
would
clone
its
privileges
or
clone
its
user
clone
security
context,
but
nothing
else
would
happen
with
that
exact
process.
C
It
would
just
potentially
keep
running.
So
that's
the
that's
the
idea.
There
might
also
be
other
cases.
Maybe
this
is
trying
to
justify
it
necessarily,
but
potentially
other
use
cases
for
that
sort
of
exact
option
to
happen.
If
you
wanted
any
sort
of
like
not
necessarily
side
core
processes,
but
you
wanted
co-processes
to
run
inside
of
a
container,
they
could
hook
into
that.
So
I'm
kind.
B
C
A
Yeah,
I
definitely
recall
playing
with
the
exact
processes-
I
don't
recall
the
context,
so
it
definitely
doesn't
sound
too
out
of
the
realm.
I
think
it
might
have
even
been
with
like
logs
right.
I
think
we
might
already
do
something
similar
for
with
logs
but
yeah.
I'm
not
entirely
sure.
I
think
the
the
part
where
I
have
a
question
is
like
who
exactly
is
it
that
is
impersonating
the
user?
Is
that
pac's
responsibility
that's
being
set,
or
is
it
that
pac
is
just
executing
this
additional
process?
A
A
So
like,
is
it
pac
itself
that
the
one
that's
you
know
setting
more
or
less
the
environment,
because,
ultimately,
I
guess
my
question
is:
is
this
something
that's
set
at
the
container
level
right
or
is
this
something
that's
set
inside
of
the
executable
aka,
the
life
cycle?
That's
doing
the
impersonation.
C
Yeah,
that's
a
that's
a
good
question,
the
life
cycle
when
it's
called
it
it's
going
to
start
receiving
it
doesn't
yet,
but
it's
going
to
start
receiving
the
dash?
U
s
id
flag,
which
will
be
the
user
id
of
the
user
to
impersonate,
and
so
that's
sort
of
where
the
the
coupling
will
happen.
Is
that
it'll
be
pack
that
will
create
this
co-process
for
life
cycle
and
then
life
cycle
will
look
it
up
by
that
id.
C
But
it
sort
of
follows
a
little
bit
the
current
obligation
of
life
cycle
to
need
to
know
what
user
to
impersonate
for
linux,
where
it
when
it
drops
privileges
down,
I'm
almost
certain
it
uses
that
uid
flag
to
do
so.
It
might
somehow
look
up.
It
might
look
it
up
differently,
but
I'm
pretty
sure
it
just
uses
that
uid
flag.
A
C
Yeah,
I
did
a
couple
approaches.
One
was
giving
more
privileges
to
the
to
the
impersonated
user,
so
we
didn't
have
to
run
it
as
root.
We
just
gave
it
that
you
know
sort
of
super
user
version
of
the
cnb
user,
but
then
it
then
lifecycle
will
drop
all
the
privileges
it
felt
a
little
risky.
It
couldn't
actually
drop
all
the
privileges
it
got
kind
of
close
to
it,
but
it
also
felt
like
windows,
starts
to
behave
way
more
different
than
linux.
C
In
that
case,
you
have
to
be
more
concerned
about
this
sort
of
supervised
user.
There's.
One
other
attempt
that
I
made
where
I
tried
to
like
stuff
the
credentials
into
the
container
image
for
this
impersonated
user.
So
that's
one
way
that
a
privileged
process
could
make
an
unprivileged
process
as
if
it
has
a
real
password
that
also
felt
a
little
a
little
scary
just
having
credentials
sitting
in
there.
So
I
this
felt
like
the
least
worst
ones
so
far,
but
granted
there
still
might
be
a
better
one
out
there.
A
I'm
trying
to
think
of
maybe
some
prior
art
or
alignment
with
other
systems,
and-
and
I
am
curious
about
something
like
I
know-
that
github
actions
is
based
off
of
something
azure
related
right
like
some
pipeline,
or
something
like
that.
I
wonder
if
that
they
have
a
capability
and
whether
their
implementation,
like
they
have
a
capability
to
essentially
draw
permissions
right.
As
I
know
again,
I'm
trying
to
relate
it
to
things
that
I'm
working
on
so
like
techton
and
openshift.
They
have
ways
to
essentially
affect
the
privileges
and
permissions.
C
C
Go
ahead:
okay,
yeah
I
mean
in
general.
It
does
feel
like
a
weird
requirement
for
any
platform
to
just
make
a
extra
process
that
lifecycle
can
can
clone
from
right
now.
Obviously,
packers
can
be
the
one
that
we
all
started
out
with,
but
I'm
a
little
concerned
long
term
how
we
have
other
platforms
support
this
kpac.
It
doesn't
look
like
it's
going
to
affect
them
because
they
never
need
to
run
in
a
privileged
mode.
They
can
run
since
they're
not
trying
to
talk
to
the
demon
socket.
C
B
B
You
know
a
bit
pre-occupied
pre-occupied
with
an
incident
going
on,
but
the
I
wanted
to
mention
likes
to
keep
in
mind
stack
packs,
because
I
believe
that
it's
sort
of
expected
that
it
will
be
in
an
elevated
mode
and
then
dropping
down.
So
I
do
think
that
so
we
probably
won't
want
to
make
sure
we
keep
that
in
mind.
I
I
said
I
wasn't
following
along
completely,
but
it's
something
to
like
keep
in
our
heads
like.
B
A
C
That's
a
good
call
yeah.
I
think
this
model
that
I
came
up
with
actually
should
be
the
best
fit
for
it.
It
doesn't
doesn't
have
to
switch
processes
and
it
does.
It
will
guarantee
that
it's
the
exact
same
valid
user
that
it
drops
privileges
to,
rather
than
just
trying
to
guess,
yeah
and
and
in
general,
in
terms
of
stack
packs.
I
do
I
I
this
may
be
another
tangent
too,
but
I
do
feel
pretty
confident
that
we
can
come
up
with
a
way
to
consume
stack
packs
before
we
can
actually
author
them.
C
A
Yeah,
I
was
gonna
say
because
if
it
was
only
the
dr
damon
case,
I
had
already
advocated-
and
I
think
emily
might
have
been
aligned
with
dropping
the
daemon
case
and
just
supporting
registry
only
and
then
pack
kind
of
changing
its
implementation
to
have
an
ad
hoc
registry
that
then
it
pumps
into
the
daemon
and
that
would
have
completely
removed
the
daemon
case
and
thereby
the
elevated
privileges,
but
because
of
stackpack
right
like
that's,
not
going
to
go
away
anytime
soon
or
any
time
now
so.
Yeah.