►
From YouTube: SIG-Auth Bi-Weekly Meeting for 20220720
Description
SIG-Auth Bi-Weekly Meeting for 20220720
C
I
just
threw
these
in
here
to
get
eyes
on
them.
These
were
a
couple
bugs
that
got
identified.
I
think
they
were
late
last
release.
That
seemed
like
things
we
should
try
to
address
in
the
125
time
frame.
They
are
pretty
long
standing,
so
I
don't
know
that
they
are
like
the
severity
is
high,
but
their
correctness
issues.
So
it
would
be
good
to
get
them
addressed
this
one.
I
don't
think,
has
anyone
actively
working
on
it?
I
think
it
got
assigned
a
while
ago
and
I
haven't
seen
any
activity.
C
C
A
B
D
If
we
were
going
to
try
to
like
directly
call
the
marshall
functions
on
the
on
that
prototype.
Or
would
we
want
to
use
the
protobuf
serializer
we
have
which
wraps
the
whole
thing
in
the
runtime
that
unknown
thing
or
the
type
metasta,
which
then
leads
to
the
question
of?
If
we
did
the
latter,
then,
are
we
going
to
basically
have
like
conversioning
of
this
new
protostructure,
which
we
will
then
I
guess
bump
and
maintain
and
test
for
basically
how?
D
A
A
D
The
weirdness
of
that
flexibility
is
now
you're
like
storing
you're,
storing
a
runtime
down
unknown
with
type
meta
information.
So
now
you
have
to
have
type
meta
information
right,
like
you
have
to
declare
an
api
version
and
stuff
for
the
thing
that
you're
going
to
store
in
there,
because
you're
effectively
saying
that
that
encrypted
object
is
like,
for
example,
the
equivalent
of
like
a
pod
or
something
right
like
you're.
You
have
like
that
layer
of
indirection,
so
you
get
a
bunch
of
flexibility
from
that
layer.
D
D
A
C
What
moe
was
talking
about
reminds
me
of
how
we
had
to
do
like
envelope,
wrapping
of
proto-encoded
stuff
to
add
like
an
api
version
kind,
but
I
will
admit
that
my
proto
serialization
foo
is
weak,
and
so
maybe
there
are
facilities
for
doing
that
version
like
self
self
identification
and
serialized
content
that
we're
not
taking
advantage
of.
I'm
I'm
just
not
very
familiar
with
what
is
possible.
B
B
C
E
Yeah,
so
with
this
question
we
are
adding
some
overhead
right
like
because
etcd
objects
are
limited
to
one
megabyte
and
adding
encryption
adds
some
small
overhead.
But,
like
now
we
add
a
lot
more
data
in
terms
of
head
to
each
secret.
So
we
could
run
into
secrets
not
being
able
to
store
being
able
to
be
serialized
to
etcd
without
in
the
new
version
where
it
would
have
been
possible
in
the
world.
D
So
you
have
to
remember
those
secrets:
are
size
limited
by
the
api
server
first
with
a
much
smaller
size
than
the
maximum
lcd
size
limit.
So
I
don't
think
you
can
actually
practically
hit
that
case
because
our
api,
our
api,
doesn't
like
you
storing
a
bunch
of
bytes
and
secrets
because
we're
not
your
database.
D
D
B
D
E
A
B
D
And
that
would
only
be,
I
think,
if
you
wanted
to
make
a
change
that,
like
an
old
api
server
using
the
old
schema,
would
confuse
or
lose
data
or
do
something
weird,
so
it
would
be
purposely
saying
hey.
I
want
this
v2
thing
and
I'll
do
like
you
know
a
graceful
rollout
of
the
capability
of
being
able
to
read
such
a
thing,
but
I
won't
write
as
it
for
some
like
another
release,
etc,
etc.
D
A
C
C
Trending
towards
code
freeze:
let's
make
sure
that
the
people
who
should
be
reviewing
things
are
like
assigned.
So
if
it's
assigned
to
mo-
and
you
were
going
to
look
mike,
maybe
assign
yourself
and
then
we
can
try
to
get
like
order
of
a
day
or
two
turnarounds
on
things.
Otherwise,
we
won't
make
progress
towards
cook
trees.
D
E
A
B
D
B
D
B
B
C
The
more
useful
I've
kept
is
to
capture
that,
if
we're
intending
this
to
be
like
a
self-driving
thing,
where
there's
no
user
toggle
switches
and
there's
no
like
action
required,
and
it's
not
user
surfaced,
then
maybe
it's
like
fully
an
implementation
detail.
I
I
haven't
dug
in
to
this
enough
to
know,
but.
A
A
A
C
E
C
E
D
It's
it's
been
a
while
rita,
and
this
and
everyone
knows
who
had
these
conversations
that
we
were
talking
about.
I
think
we
think
we've
voted
for.
No,
we
will
not
include
any
details
about
this.
It's
an
implementation
detail.
We
have
to
change
the
whole
bumper
version
and
we'll
pick
whatever.
The
other
thing
is.
B
B
D
A
A
E
A
A
C
This
seems
in
line
with
other
types
of
validation,
fixes
that
we've
made,
where,
like
internally
validation
like
tolerated,
relaxed
data
but
didn't
on
update
but
didn't,
allow
it
on
create
for
release
and
then
did
the
next
level
of
enablement
the
next
release,
and
there
were
no
user
knobs,
no
feature
gates.
No
cap,
it
was
like.
Oh,
we
found
a
validation
bug
and
we
fixed
it
over
two
releases.
A
A
D
A
C
B
C
C
B
C
D
C
B
B
B
C
C
C
Yeah,
I
mean
at
this
point
we're
probably
far
down
enough
that,
like
there
have
been
failures
in
the
last
couple
weeks,
this
this
is
the
local
ede,
which
seems
like
that
job
itself
has
a
problem
and
it
doesn't
look
like.
We've
got
recent
regular
flakes
in
any
like
core
jobs
or
jobs
that
we
own.
So
that's
good.