►
From YouTube: Scorecards Biweekly Sync (March 10, 2022)
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).
B
B
A
D
Hey
y'all,
rich
aeronymous
from
from
ibm
thought,
I'd
sit
in
and
just.
E
D
Today
been
I've
been
following
the
project
and
hey
naveen
good,
to
see
you
yeah
hope.
H
Hey
folks,
I
I
guess
we
can
get
started,
I'm
sure
people
will
keep
joining
in.
I
I
see
more
new
folks.
Anyone
wants
to
introduce
yourself
if
it's
your
first
time
here.
Let
us
know
you
know
how
we
can
help
you,
how
we
can,
what
you're
looking
to
get
out
of
scorecards.
D
Yeah,
I
I
can
jump
in
I'm
a
rich
aeronymous,
I'm
an
ibm's,
open
source
group
and
working
on
supply
chain
security
issues
within
ibm,
been
following
the
project
and
hoping
I
can
find
some
ways
to
contribute.
I
H
Cool
good
to
have
you,
anybody
else
wants
to
go.
H
Cool,
I
guess
that's
all
one
quick
thing
before
we
get
started.
I
I
just
wanted.
This
is
more
of
an
admin
thing.
I
am
thinking
of
updating
the
bi-weekly
to
say,
scorecards
and
all-star.
I
think
we
should
be
discussing
both
of
those
topics
here.
So
just
wanted
to
know
if
anyone
had
concerns-
or
you
know
what
folks
thinks,
if
everyone's
okay
with
it,
I
can
go
ahead
and
update
it
officially.
E
I
I
think,
there's
high
overlap
and-
and
I
want
to
talk
about
repo
management
later
and
really
lean
on
on
jeff
around
the
all-star
stuff.
Part
of
this
is,
I
think
we
need
to
so
as
we
build
out
new,
scorecard,
repos
and
think
about
testing
and
stuff
there's
a
huge
overlap
between
the
maintainer
pool
and
it
might
make
sense
to
make
sure
all
of
the
github
teams
are
configured
in
a
way
that
all
of
us
can
can
kind
of
contribute
and
and
do
reviews
so
I'll
get
into
that
later,
though,.
C
I
conclude
the
only
thing
that
already
our
scorecard
meetings
are.
We
don't
need
to
discuss
lots
of
debt
work
as
long
as
we
schedule
time
box
stuff,
I'm
all
for
it.
I
just
wanted
to
just
let
that.
H
Make
sense
jeff,
do
you
have
anything
good.
J
Yeah
that
sounds
good
yeah,
as
naveen
said.
If
we
do
end
up
needing
the
time
we
could
move
to
weekly,
we
moved
to
like
switching
strategy
and
implementation,
maybe
alternating
week
week
to
week
I
don't
know
but
let's
play
by
ear
and
see
how
it
goes.
E
I
I
would
say
we
do
a
little
bit
of
of
everything,
keep
the
bi-weekly
for
now
and
if
we
need
to
ramp
up,
we
do.
I
think
that
we
have
just
enough
content
to
cover,
within
the
kind
of
bi-weekly,
cadence
and
and
few
enough
maintainers,
that
it
may
not
make
sense
to
increase
the
cadence.
H
E
So
yeah,
so
one
note
on
the
meetings
like
when
we
do
the
updates.
We
want
to
make
sure
that,
like
one
sweep
all
of
the
scorecard,
repos
and
and
all-star
for
contact
information
like
we
should
just
have
a
single
place
for
contact
information
like
where
to
go
to
get
help
how
to
join
the
meeting
and
then
once
that
information
is
updated,
we
should
make
sure
it's
part
of
the
the
meeting
as
well.
E
So
like
the
the
the
the
notes
to
the
the
the
google,
like
the
link
to
the
google
doc
should
be
included
in
the
in
in
the
meeting
notes,
which
is
in
the
meeting
invite
which
is
not
today.
Also,
we
want
to
make
sure
that
for
any
of
the
maintainers,
any
of
the
maintainers
have
access
to
also
run
the
meeting,
so
post
keys,
host,
keys
being
able
to
share
cohost
and
all
that
stuff.
H
E
I
don't
believe
it
does.
I
I
do
this
every
time
I
join
the
meeting.
I
oh
it
does
never
mind.
I
think
one
of
the
links
was
broken
before
it's.
It
may
be
on
the
scorecard
repo,
where
the
the
link
for
the
meeting
does
not
include
the
password.
So
if
you
don't
know
the
password
you
you
hope
you
need
to
hope
that
you
have
the
invite.
H
E
The
meeting
is
password
protected,
so
the
I
think
the
link
to
the
the
meeting
on
the
scorecard
repo
does
not
include
the
password.
So
if
you
don't
already
have
the
meeting
in
your
calendar,
then
then
you're
not
coming
yeah.
C
E
So
I
think
it's
fine
to
add-
and
this
kind
of
goes
into,
the
maintenance
component
making
sure
all
the
maintainers
have
host
key
to
to
grab
host
and
and
to
use
the
moderation
tools.
E
We
ran
into
the
same
thing
with
kubernetes,
where
we're
sharing
like
new
meeting
stuff
and
we're
getting
zoom
bombed
occasionally,
but
I
think
it's
fine
to
include
the
password
publicly
or
in
a
place
where
only
people
who
have
access
to
the
doc
have
access
to
the
password.
But
that's
also
exclusionary,
because
if
people
cannot
access
the
google
docs
in
google
docs
in
general,
then
they
won't
be
able
to
get
the
password.
E
H
That's
good
yeah.
I
quickly
wanted
to
jump
into
this
like
this.
This
discussion
about
rohan's
plan
the
intern
plan
that
he's
working
on,
because
I
think
there's
some
confusion
going
around
in
the
scorecard
maintainers,
but
before
we
go
into
that,
I
I
just
wanted
to
ask:
does
anyone
have
any
topics
that
yeah
you
know?
H
I
think
a
new
a
lot
of
new
folks
have
joined,
so
any
topics
that
you
guys
wanted
to
add
to
the
agenda
that
we
are
missing
right
now
or
should
we
just
jump
into
our
open
items.
E
I
I
think
for
like,
maybe
not
for
this
one,
but
for
future
meetings
like
let's.
A
lot
of
these
topics
are
kind
of
assigned
to
maintainers,
so
we
have
an
update
section
and
we
also
have
the
open
issues
which
leave
the
open
issues
for
like
non-maintainer
community
stuff
and
pull
the
maintainer
level
updates
into
our
respective
areas.
H
That
sounds
good
cool
right.
Maybe
do
you
want
to
go
ahead?
You
know
talk
through
your
design
and
you
know
we
can
take
some
questions.
If
folks
have
them.
F
Yeah
sure
I
have
a
document
if
that's
okay,
to
screen
share.
E
Can
you
also,
can
you
also
include
a
link
to
the
document
and
make
it
comment
open
for
for
folks
on
the
call.
B
H
E
H
K
B
It
possible
not
to
share
it
to
the
mailing
list,
so
we
don't
have
to
join
yet
another
google
group
to
get
access
to
documents
and
just
make
it.
Anyone
who
has
the
link
can
comment.
B
E
K
E
Rohan,
if
you
give
me
if
you
can
give
me
access
to
the
doc
and
I'll
drop,
my
my
name
in
chat,
if
you
give
me
access
to
the
doc
I'll,
create
a
non-google
one
and
then
open
access
to
that
one,
and
then
we
can
use
that
one
moving
forward.
H
F
Okay,
so
I'll
start
off.
F
Here
one
sec:
sorry
thank
you!
Yeah,
okay,
we
get
I'll,
try
to
figure
out
the
sharing
later,
but
for
now
I'll
just
go
ahead
with
this.
So
basically
like
the
idea
behind
this
project
that
I've
been
working
on
for
the
past
few
weeks
is
to
basically
crowdsource.
These
scorecard
runs.
So
currently,
the
scorecard
is
run
weekly
on
like
over
a
million
repositories,
and
this
is
like
a
big
strain
on
our
computing
power
because
we're
running
it
using
our
servers.
F
So
what
we're
going
to
do
is
we're
going
to
use
cosine
to
write
a
signature
on
the
results,
and
this
is
going
to
use
a
github
attestation
through
oidc,
so
that'll
basically
make
sure
that
that
signature
is
secure,
and
this
will
allow
us
to
later
on
be
able
to
verify
that
a
certain
scorecard
result
actually
corresponds
to
the
repository
that
someone
is
claiming
that
it's
been
run
on
and
also
aside
from
this,
we're
also
going
to
implement
a
badge
service.
F
F
The
first
component
of
this
design
is
the
signing
via
open
id
connect.
So
currently,
when
the
scorecard
action
is
run,
there's
going
to
be
two
possible
results,
there's
going
to
be
the
json
and
then
the
serif
files.
So
these
two
files
combined
basically
give
us
like
enough
necessary
information
to
attribute
the
result
to
a
repository.
F
So
we're
going
to
assign
these
two
files
using
the
keyless
flow
on
the
workflow
and
then
the
attestation
of
the
signature
is
gonna,
get
uploaded
to
sigstor
and
then,
after
the
signing
is
done.
This
is
in
the
workflow.
Still,
it's
gonna
call
our
post
endpoint,
so
we're
gonna
create
a
scorecard
variation
verification.
Api
endpoint.
This
is
going
to
be
in
the
scorecard
web
app
repository,
so
we're
going
to
have
a
post
endpoint,
which
is
basically
going
to
take
the
results
from
the
workflow
from
the
scorecard
action
process.
F
Those
two
files
that
I
mentioned
earlier
and
it's
going
to
first
of
all
ensure
that
the
certificate
is
actually
associated
with
that
repository.
So
it's
going
to
look
up
the
entry
of
that
signature
and
verify
the
repository
and
the
branch
associated
with
it.
And
then
another
thing
we're
going
to
do
is
we're
going
to
pull
the
workflow
that
what
that
the
scorecard
action
was
actually
called
from.
F
So
we're
going
to
scan
this
workflow
to
make
sure
that
it
only
has
the
definition
that
matches
our
template,
so
we're
going
to
only
going
to
allow
the
four
steps
that
are
actually
necessary
for
scorecard
action
to
be
run
through
the
workflow,
and
this
is
going
to
make
sure
that
within
the
workflow
there's
nothing
malicious
going
on.
So,
for
example,
someone
can't
call
scorecard
action
and
then
have
their
own
step
in
the
workflow
that
modifies
their
results
before
the
signature
is
processed.
F
So
that's
going
to
catch
all
those
issues.
It's
also
going
to
check
for
stuff
like
environment
variables
and
like
permissions
that
shouldn't
be
set.
So
that's
basically
like
the
basis
of
the
authenticity
authenticity
of
the
results
that
this
workflow
file
that
is
attached
to
the
results
actually
matches
our
template.
F
F
All
it
does
is
just
it
takes
in
like
a
repository
and
a
branch,
and
it's
gonna
provide
the
most
recent
score
if
it
exists,
and
these
scores
are
all
guaranteed
to
be
authentic
because
of
the
previous
verification
that
happened
in
the
post,
endpoint
and
then.
Lastly,
this
is
again
the
scorecard
badge
service.
So
it's
gonna
look
something
like
this.
F
Where,
as
you
can
see
in
the
url,
you
would
have
so
right
now,
everything's
github,
but
we're
also
planning
on
expanding
it
to
other
providers
like
if
we
had
git
lab
or
something
like
that,
and
then
you
would
also
have
the
organization
and
then
the
repository
as
the
parameters,
and
then
it
would
provide
you
with
like
a
little
image
that
you
can
attach
on
your
readme
just
to
show
like
all
your
users,
what
the
general
like
security
measure
of
the
project
is
so
yeah.
C
A
question
here,
so
how
long
are
these
scores
to,
if
I'm
a
malicious
user
I
could
get
a
high
score,
then
not
run
the
action
like
I
could
get
a
high
school,
not
run
the
action
for
x
number
of
days.
I
turn
off
that
action
and
still
have
a
high
school,
have
malicious
code
in
mind.
So
how
long
the
validity
of
the
score,
or
is
it
on
a
comment
shop.
F
It's
based
on
the
commit
shot,
so
the
certificate
that's
generated
from
the
workflow
being
run.
It's
attributed
only
to
that
specific
commit
shot.
So
if
the
repository
is
modified
in
any
way,
we
can
see
that.
C
But
would
the
badge
be
able
to
pick
up
pick
it
up
like?
Like?
Did
you
know
what
I'm
trying
to
say?
Like
I
s,
I
run
yeah.
I
ran
my
score
yesterday
and
today.
Obviously
there
are
five
more
comments
that
have
gone
and
the
badge
is
still
gonna.
Show
me
an
eight
and
it
could
be,
it
could
either
be
malicious
or
it
could
be
like,
like
not
everybody's,
going
to
get
for
every
comment
into
a
scorecard
yeah.
So
so
have
you
thought
about
that.
H
C
H
Probably
try
and
answer
that
so
yeah
like
trying
to
avoid
maliciousness
and
the
badge
itself
is
kind
of
autoscope.
The
reason
being
I
mean
you
don't
even
have
to
be
malicious
right.
You
can
basically
put
in
your
readme
a
badge
for
some
other
repo
and
we
can't
actually
check
it.
So,
in
a
way,
the
badge
is
not
really
something
that
is
like
hiding
some
kind
of
provenance
or
attestation.
H
It
is
really
for
the
maintainers
to
show
what
the
score
is,
the
authentic
part,
or
rather
the
integrity
of
it,
comes
from
the
api
that
rohan
is
generating,
because
that
will
always
tell
you
like
for
this
commit
shot.
This
was
the
score
score
recorded,
and
these
were
the
you
know,
details
recorded,
so
the
integrity
comes
in
the
api
generated,
rather
than
the
badge
that
it
shows
up
on
the
repo.
H
That
gets
generated
when
we
run
scorecard
cli
today.
We
should
ideally
store
the
whole
thing
and
the
c
json,
like
the
runtime,
the
shot
which
the
scorecard
ran
sure,
because.
C
E
I
Now
I
just
wanted
to
ask:
is
there
a
decision
made
on
how
the
data
that
can
be
retrieved
from
this
api?
What
kind
of
format
will
it
have?
Is
it
going
to
be
playing
jason
or
jason
ld?
Maybe.
H
So
we
we
are
planning
to
do
a
more
detailed
design
and
discussion
on
that
later.
But
as
of
now,
since
it's
like
a
v0
it'll
it'll
match
exactly
what
you
see
when
you
run
scorecard
cli,
you
know
minus
format
json,
so
we
want
to
keep
the
format
consistent
with
what
you
would
see
there,
but
there
is
a
long-term
discussion
to
be
had
as
to
you
know
how
this
should
be
exposed.
E
So
I'm
going
to
make
some
some
googly
comments
based
on
things
that
I've
seen
in
other
projects.
I
want
to
stress
the
importance
of
like
we
we're
we're
talking
about
it
now
and
that's
super
awesome
and
because
it's
v0,
that's
even
awesomer.
I
want
to
stress
the
importance
of
like
when
we
have-
and
I
included
in
my
section
but
like
we
should
at
some
point
have
a
longer
discussion
about
like
what
proposals
look
like
or
what
they
need
to
look
like.
E
So
I'm
I
with
my
with
my
kubernetes
hat
on
I'm
one
of
the
co-creators
for
the
kubernetes
enhancement
proposal
process,
and
I
think
that
is
like
it's
it's
great.
It's.
It's
got
some
nice
things,
but
it's
also
it's
also
heavyweight
for
for
for
folks
what
I
notice
a
lot,
and
especially
in
in
areas
that
I'm
involved
in
so
like
release
engineering
testing,
is
that
we
get
these
proposals
from
googlers
that
are
maybe
not
maybe
not
to
the
spec
of
that
community.
E
I
think
it's
okay
right
now,
because
we
don't
have
an
expectation
of
what
that
spec
should
be,
but
we
should
create
it
and
when
people
are
coming
with
proposals,
google
internal
or
what
have
you
like
often
something
will
get
like
well
formed
on
the
google
side
and
then
it'll
show
up
in
the
community
and
a
lot
of
people
will
wonder.
Where
did
this
discussion
happen?
E
Why
wasn't
I
a
part
of
it
like
there
are
some
design
decisions
made
that
I
don't
necessarily
agree
with,
or
you
know
for
for
a
lot
lots
of
instances,
design
decisions
made
and
implementation
happening
and
then
not
having
that
support
from
you
know
not
having
that
support
to
maintain
that
implementation
right.
So
I
think
I
I
just
want
to
stress
that
it's
very
important
that,
like
we
decide
what
designs
look
like,
I
think
this
is
great
just
to
be
clear.
This
is
not
about
the
specific
design.
E
It's
it's
about
things
that
I've
noticed
in
other
communities
coming
from
the
google
side,
so
I
like,
I
think
I
I
think
we
have
an
opportunity
to
fix
it,
and-
and
I
would
like
to.
B
I
think
that's
a
really
great
point
to
define
these
things
up
front
and
get
out
in
front
of
it.
I
mean
not
just
google,
but
I've
been
in
several
communities
where
you
know
things
suddenly
get
popped
on
them.
Like
you
know,
athena
bursting
fully
formed
out
of
the
head
of
zeus.
It's
here's,
this
fabulous
thing
and
the
community's
like
well
that's
nice,
but
where
did
that
come
from
so
being
able
to
to
set
expectations
in
advance
allows
us
to
hold
people
to
those
expectations.
B
So
I
don't
know
whether
augie
you
have
any
suggestions
for
moving
forward
with
that
or
whether
you
would
like
to
put
that
on
the
agenda
for
future
calls,
because
it
looks
like
we've
got
some
other
things
we
might
want
to
cover
today,
but
I'm
a
big
plus
one
on
pretty
much
everything
you
said:
yay
go
stephen.
E
Yeah
I
mean
long
term
we
can,
we
can
we
can
hash
it
out.
I
think
you
know
the
so
kubernetes
enhancement
proposals
were
inspired
by
like
python
peps
and
the
rest
rfcs.
So
there
is
lots
of
information
to
draw
from
that
they're.
Also
like
lighter
weight,
architectural
architectural
decision
records
or
adrs.
We
use
some
of
that
in
like
inclusive
naming
initiative,
but
it's
you
know,
obviously,
for
inclusive
naming.
E
Less
technical
than
then
an
implementation
here
so,
like
I,
I
love
seeing
this
because,
like
so
I
can,
I
can
put
up
an
issue
or
a
discussion
point,
and
we
can.
We
can
start
there.
I
love
seeing
this
design
because
it
helps
inform
why
some
of
the
pushes
are
happening
like
so.
Rohan
is
also
working
on
changes
and
scorecard
action,
and
I
was
like
like
where's
this
coming
from
like
so
now.
E
I
know
exactly
how
the
story
ties
together,
so
getting
this
information
out
sooner
rather
than
later,
and
definitely
ahead
of
implementation,
because,
like
some
of
these,
things
are
already
in
flight
right,
and
does
that
mean
that
it's
on?
E
Does
that
mean
that
it's
on
that
we're
beholden
to
some
new
expectation
as
maintainers
and
as
contributors
that
we're
not
aware
of
right
so
even
more
important
to
get
get
things
out
earlier
rather
than
later,
so
the
community
community
can
kind
of,
like
you
know,
swarm
on
it.
C
Totally
different
thing
on
the
json
that
that
rohan
and
azim
were
mentioning
on
the
output.
That
means
we
need
to.
C
How
are
we
going
to
versioning
like
we
need
to
think
about
like
like
everything
about
versioning,
because
if
we
add
additional
features
to
json
like
do
we,
because
now
it's
a
web
api?
Do
we
do
we
stick
to
that,
like
all
those
conversations
has
to
be
thought
through,
if,
if
there
is
something
that's
going
to
be
because
now
we're
publishing
this
video
endpoint
we're
going
to
I'm
hoping
that's
a
contract
that
we're
going
to
stick
to
for
the
lts,
so
we
thought
through.
Yes,
sorry.
E
Yeah,
so
I
I
have
a
very
vague
topic
on
my
updates
is
like
what's
an
api
right
and
we're
we're
starting
to
we're
starting
to
get
these
these
multiple
areas
that
want
to
consume
what
we're
working
on
right.
So
you
look
at
scorecard
action
as
an
example.
All-Star
is
an
example.
Witness
is
another
example
right,
this
api
right.
A
lot
of
the
stuff
needs
to
live
in
scorecard.
E
It
needs
to
live
as
an
api
and
scorecard
and
and
a
contract
that
we
maintain
additionally
like
around
versioning
and
stuff,
like
that,
we
need
to
understand
compatibility
right
so
like
we
have
mentioned
december
in
the
past,
and
we
already
used
semver
if
you're
using
semver.
There
is
even
though
not
everyone's
doing
it.
There
is
some
soft
expectation
that
you
are
trying
to
adhere
to
the
expectations
that
december
lays
down,
so
I
think
we
should
be
working
towards
doing
that.
I
say
all
that
to
say
all
of
this
comes
from.
E
All
of
this
should
be
rooted
in
scorecard
right,
so
we
have.
We
have
kind
of
things
in
place
right
now.
We
have
like
some
of
the
future
flags
for
like
v5
v6
enable
serif.
What
not
we
need
to
refine
the
way,
we're
doing
that
so
that
we
can
say
like
yes,
if
you're
building
out
this
feature
it
needs
to
it
needs
to
live
under.
E
It
needs
to
live
under
the
v5
flag
right
and
it
and
it
doesn't
and
like,
and
it's
completely
disabled
unless
people
want
to
to
test
the
waters
right,
but
it
all
needs
to
it
all
needs
to
live
in
scorecard
and
everything
else.
You
know
every
consumer
builds
on
top
of
that.
H
Yeah,
I
I
think,
just
for
the
interest
of
time
I
kind
of
want
a
table
discussion
so
that
we
have
enough
time
for
other
topics
too.
I,
st
stephen,
I
I
know
you
wanted
to
have
you've
added
a
bunch
of
updates
that
I
know
you
want
to
discuss.
Is
this
the
same
thing
that
that
you
you
were
mentioning
now?
Is
there
something
you
want
to
take
later
or
is
there
something
specific
you
want
to
bring
up
now.
E
So
I
I
guess
you
know,
as
part
of
my
updates
I'll
say
that
you
know
the
I've
started
to
poke
around
at
the
whole.
What's
an
api
question
right,
so
you
know
two
of
our
consumers.
We've
got
the
scorecard
action
and
and
all
star
I
started
an
initial
pr
for
for
all-star
and
jeff.
E
I
don't
know
if
you've
had
a
chance
to
take
over
that
thing,
but
effectively
we
want
to
be
able
to
to
expose
all
of
the
checks
that
you
can
do
within
scorecard
in
all-star
right,
so
so,
and
and
ideally
we're
not
writing
the
same
checks
for
for
all-star
that
are
already
exist
in
scorecards
right.
So
right
now,
the
I
think
the
the
highest
fidelity
endpoint
that
you
have
for
scorecard
is
just
to
use
the
the
cli
tool
right,
because
all
of
the
validation
for
the
options
is
happening
already
within
it
right.
E
So
so
part
of
the
work
that
I've
been
doing
is
kind
of
like
restructuring
the
restructuring,
the
cli,
so
that
you
can
essentially
remix
it
and
then
so.
Some
of
the
options,
some
of
the
options
have
been
pulled
out
into
a
separate
package,
and
you
know
the
options
are
now
struct,
which
you
can
add
flags
to.
So
the
way
the
cli
is
built
is
essentially,
you
instantiate,
a
new
you
instantiate,
a
new
option
set.
You
add
the
flags
to
the
option,
set
it
pop.
E
It
auto
populates
some
defaults
right,
and
that
means
that
anyone
who
is
anyone
who's
using
like
scorecard
command
or
whatever
it's
exported,
as
has
the
ability
to
say
they
will
automatically
they
will.
They
will
automatically
get
validation
for
those
options,
including
if
they
you
know
in
in
the
the
case
of
like
scorecard
action
where
we're
kind
of
using
environment
variables
to
make
decisions
right.
E
So
when
you
populate
the
option,
struct
it's
using
the
the
guy
carlos
who
maintains
go
releaser
has
a
has
a
package
called
like,
I
think
it's
like
env
or
something
env
v6
right,
and
you
can
specify
tags
for
your
struct
that
if
those
environment
variables
exist,
they'll
auto
populate
them
right.
So
I
worked
around
some
of
that
by
doing
that,
so
the
scorecard
the
new
version
of
scorecard
action
will
be
golang
based
instead
of
instead
of
an
entry
point,
a
shell
entry
point.
E
I
will
also
note
that
the
shell
entry
point
is
not
actually
an
entry
point
right
now,
so
we're
running
into
issues.
Rohan
you'll,
you'll
see
and
you're
you're
kind
of
working
through
it
on
your
pr
and
I'm
working
through
it
in
other
ways
on
the
side
that
the
the
entry
point
is
kind
of
inflexible
right,
because
it
just
assumes
you're
going
to
do
that
thing
and
that's
it
right
and
an
entry
point
should
allow
you
to
pass
options
into
it.
The
default
state
of
it.
E
You
should
be
able
to
run
the
the
container
image
and
it
spits
out
the
help.
The
help
usage
right
unless
you
pass
a
command
into
it
right,
we
can
default
to
command,
but
right
now
we're
not
we're
basically
saying
entry
point
run,
so
I'm
going
to
kind
of
expand
that
so
that
we
can
choose
whether
we
run
the
the
bash
version
of
it
or
the
go
version
of
it
right.
That'll.
E
Allow
us
to
do
some
testing
in
the
background,
as
we
build
out
like
the
ede
suite
for
scorecard
action,
and
then
we
can
say
all
right:
we're
ready
to
flip
the
switch
right.
So
the
first
stage
is
kind
of
working
on
making
sure
that
the
making
sure
the
command
is
importable,
which
it
is
today,
and
then
there
is
some
logic
within
the
command
that
we
can
push
into
like
package.run
scorecards.
E
J
Sounds
like
you
have
a
vision,
do
you
have
any
like?
Did
I
write
it
down?
J
E
Absolutely
absolutely
so:
I'm
gonna
share
my
screen
for
a
hot
moment.
Let
me
know
if
you
can't
see
it
actually,
just
let's
go
to
the
command
line.
E
I
don't
think
I
have
the
things
I
need
here
on
this
laptop,
but.
E
So
this
will
give
you
an
example:
it's
bigger,
so
within
so
main.go
for
scorecard
action
is
essentially
just
calling
entry
point
new
entry
point.
New
is
going
to
create
a
new
cobra
command
and
then
doesn't
execute
of
the
cobra
command
right.
If
we
go
back
into
what
entry
point
is
actually
doing,
you'll
see
that.
So,
if
you,
if
you
ask
for
a
new
entry
point,
you
ask
for
a
new
command
from
the
entry
point
package.
E
E
You
know
some
specific
setting
of
options
for
scorecard
action
and
then
we're
just
saying
that
the
that
the
so
as
a
result
of
as
a
result
of
of
creating
the
new
the
new
options
you're
also
going
to
get
a
stack
of
of
the
scorecard
options
right
so
they're
the
scorecard
action
options
and
then
the
scorecard
options
and
there's
a
little
bit
of
overlap
to
account
for
environment
variables.
E
You're,
creating
a
new
at
this
point:
you're
creating
a
new
command
and
the
new
command
is
based
on
the
scorecard
command
right
and
what
I'm
doing
is
I'm
layering.
On
top
of
this
command,
I
added
a
new
flag
to
allow
you
to
output
results
because
within
our
entry
point,
we're
basically
piping
them
to
to
a
results
file,
and
then
I'm
modifying
the
the
pre-run
execution
for
the
action
command,
and
I'm
also
doing
a
little
bit
of
cleanup
a
little
bit
of
cleanup
here.
E
So
there's
some
flags
that,
within
the
context
of
the
scorecard
action
you
don't
really
care
about.
So
the
npm
pi
pi,
ruby,
gems
flags,
and
then
I
mark
all
of
them
as
hidden
right.
So
it's
still
you're
still
running
the
scorecard
com,
the
the
flags
hidden
and
some
of
the
and
some
additional
flags
and
then
finally,
I'm
adding
this
print
command
as
a
debug
to
be
able
to
say,
like.
E
E
It's
not
overly
complicated,
but
it's
not
actually
possible
to
do
if
you
kind
of
do
the
classic
configuration
of
a
cobra
application,
if
you,
if
you
have
a
bunch
of
inits
within
your,
you
know
your
root,
commands
and
stuff
like
that,
then
you
pre-configure
a
lot
of
the
options
before
the
user
gets
to
see
them
right,
so
so
unhiding
a
bunch
of
the
magic
making
making
the
the
addition
of
the
flags
a
part
of
the
option
set.
E
So
the
options
are
an
interface
and
then
and
then
that
allows
you
to
kind
of
remix
the
command.
Like
you
see,.
J
I
mean
like
well,
I
I
think
like
consolidating
what
the
you
know,
what
scorecard
exposes-
and
you
know
how
it
should
be
invoked-
is
a
really
good
idea.
I
worry
a
little
bit
on
all-star
side,
you
know:
are
we
going
to
be
able
to
pass
an
authenticated
transport?
Are
we
going
to
be
able
to
get
like
structured
data
out
for
the
score,
the
checks
that
were
run,
the
scores,
that
it
results,
the
errors
and
those
sorts
of
things.
H
So
yeah
I
quickly
wanted
to
jump
in
and
say.
Maybe
this
is
a
discussion
we
should
do
offline
because
I
I
mean
mean,
I
think,
there's
a
larger
group
of
people
here.
So
maybe
we
should
focus
on
something
that
you
know
everyone
can
contribute
to.
G
H
Yeah
items
too
so
yeah,
I'm
not
sure,
maybe
we
can
take
it
offline
or
if
folks
want,
we
can
continue
the
discussion.
C
Do
we
have
any
other
hard
pressing
things
like
that's,
that's
something
that
we
want
to
make
sure
that
everybody
like
laurent
or
this
community
have
anything
else.
If
not
there's
something
hard-pressing
that
we
can
decide
which
what
it
is.
H
Yeah,
I
think
laurent
had
a
bunch
of
issues
that
he's
been
meaning
to
discuss.
I
I
think,
there's
one
big
thing,
especially
about
this
web
hook,
check,
which
I
think
lauren
had
been
meaning
to
get
a
opinion
on
from
the
community
for
a
while.
Now,
there's
that
and
I
think,
a
bunch
of
other
things
on
dependency,
vulnerability
checks,
so
yeah
folks
think
this
is
something
we
can
do
offline.
H
C
E
E
So
there's
also
there's
also
an
issue
tracking
this,
which
folks
can
I'll
drop
in
the
chat
which
folks
can
check
out
and
leave
comments
about
how
they
feel
about
design
like
nothing
is
really
decided
outside
of
like
stuff.
That
is
obviously
you
know,
useful
and
kind
of
like
moves.
The
ball
forward,
so
the
come
on
computer
wow,
all
right.
So
if
my
floating
controls
will
go
away,
we've
got
the
webhook
secret.
We've
got
all
right
so
now
within
squirker.
The
the
problem
really
is
is
here
in.
E
If
we
look
at
the
command
itself
right,
because
because
this
was
built
as
kind
of
like
command
first
right,
all
of
you
know
a
lot
of
the
important
logic
is
pushed
into
the
the
root
command
right.
So
you've
got
do
some
stuff.
Do
some
stuff?
Do
some
great
stuff
initial
you
know
get
get
a
logger.
Do
some
more
stuff
get
the
docs
blah
blah
blah
right.
You
get
to
this
is
this:
is
the
meat
right
you
actually?
E
What
what
we
care
about
is
is
this
package
runs
scorecards
right,
so
the
next
step
for
me
really
is,
and
then
also
you
you
look
at
you
look
at
this
this
final
bit
right
and
it's
like
you
know,
assessing
the
metadata
doing
some
sorting,
yada
yada,
and
then
you
know,
if
everything's
cool,
then
don't
spit
out
an
error
right.
So
there
are
a
lot
of
things
that
you
know
you
today,
as
a
consumer
can
can
still
leverage
right
to
formatting.
E
The
results
like
a
lot
of
this
is
common
logic,
which
means
it
doesn't
need
to
be
in
the
command
itself
right.
So
you've
got
this
repo
results.
You
want
to
get
the
repo
results,
which
means
everything
above
this
everything
above
this
needs
to
be
handled
in
run
scorecards.
So
so
what
I
was
getting
to
is
like
the
next
step,
really
is
to
push
everything
that's
happening
here
down
into
run,
scorecards
and
then
make
sure
that
run,
scorecards
isn't
as
large.
E
I
I
I
don't
know
how
large
the
the
surface
area
of
it
is
right
now,
but
you
know
if
you're,
if
you're
looking
at
something
like
this,
where
you've,
where
you
need
to
line,
wrap
the
you
need
to
line,
wrap
the
options
that
you're
you're
the
the
arguments
that
you're
passing
to
a
command,
it
probably
means
that
the
the
the
structure
of
it
can
be
better
done
right.
So
this
is
this.
E
C
E
So
so
I
I
guess
not
that
precisely
but
say
you
know
saying
you
know:
if,
if
the
set
of
enabled
checks
say
right
includes
includes
badging
right,
then
that
needs
to
be.
You
know
like
if
it
if
it's
like,
if
the
set
of
enable
checks
includes
badging,
I'm
going
to
go
through
the
list
of
enabled
checks
and
say,
okay.
Well,
I
know
that
I
want
to
look
into
the
cii
best
practices
or
the
open,
ssf
badge,
which
means
I
need
to
turn
on
the
cii
client
right.
E
So
when
I
ask
for
a
new
client,
I'm
passing
a
set
of
options.
That
say
here
are
the
clients
that
I
want
and
I
should
only
get
those
clients
and
then
I
think
overall
we're
chatting
about
like
within
scorecard
action
and
then
also
kind
of
between
scorecard
action
and
all-star.
There's
there's
a
general
need
for
just
like
the
simple,
the
simple
github
client
right,
the
the
it's.
E
Some
of
the
clients
do
slightly
different
things,
and
I
I
forgot
who
exactly
is
planning
on
working
on
client
stuff,
but
we
were
talking
about,
go,
get
and
using
goget.
E
So
rob
you
are
unmuted
by
the
way,
so
we
were
talking
about
goget
and
like
if
we
have
a
simple
client,
that
is,
you
know,
and
a
concrete
implementation
of
the
get
stuff
and
deciding
what
we
need
out
of
that.
We
can
build
off
of
that
using,
like
you,
know,
functional
options,
pattern
or
something
to
say
blah,
blah
blah
with
transport
right
and
then
that
solves
the
the
problem
for
anyone
who
needs
transport.
E
J
Sounds
good
thanks
for
going
through
it
I'll
just
yeah,
no
problem,
all
the
issues.
K
K
So
this
this
check
can
only
work.
If
you
have
a
path
token,
it
cannot
work
work
with
a
github
token
because
it
requires
some
sort
of
ownership.
K
Access
to
the
to
the
repository,
and
so
I'd
like
to
know
like
there's,
been
some
discussion
on
whether
we
want
to
have
checks
that
may
may
not
be
available,
for
example,
through
the
github
action,
so
we
can
still
have
it
enabled
in
the
github
action,
but
users
will
have
to
use
a
path
and-
and
I
think
we
have
a
an
idea
of
trying
to
move
towards
github
tokens
which
are
ephemeral
and
don't
expose
the
identity
of
users
so
yeah.
K
I
wanted
to
ask
if
people
have
an
opinion
on
whether
we
should
do
it
or
not?
Do
it?
I
think
one
of
my
arguments.
Why
would
be
useful?
Is
we
already
have
some
some
some
checks
today,
like
branch
protection
that
where
we
don't
get
all
the
data
depending
on
whether
the
the
token
has
admin
privileges
or
not?
K
So
this
would
be
a
different
one.
Another
check
doing
this
and
I
think-
and
I
think,
even
though
it's
not
available
in
scorecard
action
well,
users
can
enable
it
with
a
path,
but
by
default
it
might
not
be
available.
K
If
we,
if
we
ask
users
to
use
a
github
a
github
token,
so
it
might
not
be
available
on
the
github
action
it
might
not
be
available
in
the
it
will
definitely
not
be
available
in
the
in
the
weekly
scan,
but
for
users
who
want
to
use
it
on
the
command
line
and
maybe
scan
their
own
repos.
Maybe
you
know
as
part
of
a
penetration
testing
of
things
like
this
for
their
own
company.
K
I
feel
there
will
be
some
value
for
it,
so
those
are
kind
of
the
arguments
and
back
to
rowan's
work
on
github
action.
If
we
send
the
data
back
to
our
servers,
we
will
have
to
be
a
little
bit
more
careful
about
not
sending
the
web
hooks
information.
K
I
think
I've
covered
kind
of
everything
that
was
in
the
in
the
tracking
issue.
If
I
forgot
some
things,
please
chime
in
I'd
love
to
hear
what's
yeah.
E
I've
got
a
bunch
of
opinions,
so
I
think
that
we
should.
We
should
try
to
better
understand
the
permissions
required
for
each
of
the
checks.
We
probably
do
are
ready,
but
we
we
should.
We
should
document
all
that
stuff
if
it
isn't
and
and
then
say
so
for,
like
I
see
no
problem
with
enabling
a
web
hook
check
outside
of
making
sure
that
it
is,
is
very
clear
to
user
off
the
bat
that
there's
you
need
this
for
this
to
function
right
so
in
the
set
of
enabled
checks.
E
When
you,
you
know
you
kind
of
pass
that
that
those
options
through
it
should
you
know
our
first
validation
path
should
be.
Can
you
do
this,
or
you
know
like?
Please
be
aware
that
for
you
to
be
able
to
do
this,
you
need
this
kind,
you
you
need
this
level
of
access
right
and
it
should
not
just
be
in
our
docs,
but
also
in
output
of
of
the
the
commands
right.
So
that's
the
first
thing
and
we
can
even
decide
that,
like
you
know,
these
are
checks
that
you
can
run.
E
These
are
checks
that
you
can
run
regardless
of
like,
like
whatever
our
baseline,
you
know,
whatever
our
baseline
level
of
permissions
is
so
if
that
is
the.
If
that
is
the
github
token
running
within
the
context
of
a
github
action,
then
we
say
these
are
the
checks
that
you
can
run
if
you're
using
a
github
token
within
a
github
action
right.
If
you
need
to
run
these
checks,
the
level
two
or
level
three
or
whatever
you
want
to
call
them
checks,
you
need
an
access
token.
E
That
has
you
need
to
create
a
pat
that
has
these
permissions
or
you
need
to.
If
you
have
org
admin
or
you
are
a
security
manager
or
whatever
configuration
for
github,
then
you
need
to
have
created
an
organization
secret
that
this
repo
has
access
to.
With
these
permissions,
the
secret
needs
to
be
named
this
for
the
the
workflow
to
work
properly.
K
Yeah,
so
when
you,
when
you
say
the
first
thing
we
need
to
check
in
code,
is
that
let's
say
you,
you
run
scorecard
without
specifying
the
the
checks
and
the
token
doesn't
cannot
cannot
run
on
the
webhooks
like
do
you
just
show
the
results,
as
I
didn't
have
permission
or
because.
E
Exactly
yeah,
so
so
I
think
I
think,
as
a
you
know,
for
user
experience.
I
want
something
like
if
I
run
a
tool
it
needs
to
work
or
it
needs
to
tell
me
as
soon
as
possible.
You
know
the
whole
return
early
like
as
soon
as
possible.
What's
wrong
right.
So
if
I,
if,
if
the
web
hooks
are
part
of
the
enabled
checks
and
it
runs
through
it-
and
it
says
like
hey-
you
have
not
set
a
github
token.
H
Yeah
one
one
thing
I
wanted
to
kind
of
raise
here
is
like
I,
I
kind
of
raised
this
point
in
the
issue
too.
I'm
trying
to
understand
like
how
how
folks
think
of
you
know
like
both
all-star
and
scorecard
as
a
product,
so
in
my
mind,
like
scorecard,
is
really
trying
to
bring
forth
all
these
security
metrics,
especially
public,
publicly
available
security
metrics
in
the
open.
So
in
fact,
most
of
the
checks
that
score.
H
In
fact,
all
the
checks
that
scorecard
runs
today
are
accessible
through
a
public
repo
except
branch
protection,
and
even
in
branch
protection
is
just
one
or
two
settings.
H
So
my
worry
with
having
a
check
like
this
is,
is
the
fact
that
can
we
get
into
a
situation
where
we,
unexpectedly,
you
know,
expose
these
private
information,
which
should
have
only
been
accessible
through,
like
you
know,
an
admin
part
or
something
of
the
sort,
and
we
end
up
causing
more
harm
than
good,
and
maybe
this
is
a
better
fit
for
something
like
all-star,
which
has
all
of
this
I
mean
it's
the
product
all-star
as
a
product
is
built
for
this.
H
Like
you
know,
you
can
privately
ping
maintainers
and
say
you
know
this
is
not
working,
so
maybe
you
should
fix
it
and
things
like
that.
So
I
want
to
understand
what
folks
think
they're
you
know
as
a
product
fit.
C
I
plus
one
regime's
comment:
I'm
a
little
bit
worried
about,
especially
when
that
have
all-star
doing
this.
Even
I've
had
similar
thought
process
on
that.
That's
my
opinion.
J
So
I
do
think
there
is
a
an
issue
where
yeah
like
if
we
say
here
you
know,
provide
your
privileged
pat
to
the
action
and
then
scorecard
runs
and
posts
the
results
publicly.
You
might
be
posting
some
results
publicly
that
you
didn't
really
want
to,
which
is
hey.
I
have
a
really
insecure
web
hook,
set
up,
which
normally
a
public
pat,
wouldn't
be
able
to
read
and
and
determine
on
that
repo
that
you
have
an
insecure
web
hook
setup.
So
I
think
that's
something
to.
J
I
do
think
there's
a
a
very
valid
use
case
for
scorecards,
not
not
all-star,
for
I
want
to
gather
information
about
a
repo
that
I
have
more
privilege
access
to
than
you
know.
It's
not
somebody
else's
repo.
I
have
my
own
repos
that
I
want
to
gather
more
information
about,
and
I
think
getting
this
score
of
you're
doing
this
right
or
wrong
on
on
your
own
repos
would
be
valuable
and
fits
in
with
the
product.
E
So
my
I
guess
my
opinion
is
that
they're
the
same
thing
in
in
ways
I
view
I
view
kind
of
all
of
these
components
that
are
flowing
in
and
around
scorecard
and
all-star
to
be
the
same
thing
right.
All-Star
is
a
in,
and
even
now
like
we're
talking
about
integrating
integrating
components
of
scorecard
into
all-stars,
so
that
we
can
expose
more
of
the
policy
right.
So
like
scorecard
is
scorecard.
Is
the
policy
and
part
of
the
implementation?
E
All-Star
is
a
concrete
implementation
and,
like
you
know
when,
when
all
of
that
is
exposed,
also
is
a
reporting
mechanism
for
scorecard
within
the
context
of
github
right,
there's
nothing
to
stop
someone
from
writing
an
all-star
implementation
that
would
work
on
a
gitlab
that
would
work
somewhere
else
right
so,
like
I
view
it
all
as
like
components
of
the
same
quote:
unquote:
product
right,
it's
it
and-
and
this
kind
of
goes
back
to
the
the
api
stuff
right.
How
we
design
this.
E
Like
so
there's
a
you
know,
so
one
of
the
one
of
the
implementation
paths
is
creating
a
command
right
either
way
there
is.
There
is
some
point
at
which
you
want
to
get
results
right,
so
whether
you're
getting
results
from
scorecard
and
you're,
getting
it
on
the
command
line
in
the
table,
json
sarif.
What
have
you
or
you're
getting
some
some
prettified
view
of
the
results
in
a
github
issue?
I
think
that's
just
a
reporting
mechanism,
so
I
kind
of
view
them
all
with
the
same
product.
K
So
if
it's
an
issue
about
sorry
to
get
back
to
the
action
and
leaking
sensitive
data,
we
can
make
we
can
make
by
default.
The
github
action
not
use
any
of
those
sensitive
checks,
and
then
we
can
ask
users
to
enable
it
explicitly
via
their
command
to
the
action.
K
You
know
the
action
takes
some
arguments
like
what
format
do
you
want
serif
and
I
forgot
the
other
one,
but
we
can
make
something
specific
saying.
I
want
to
enable
checks
that
need
a
path
or
something
and
and
if
that's
not
set,
even
if
you
use
a
path,
we're
not
going
to
run
those
checks.
E
Yeah,
that
that
makes
sense
to
make
it
hard
for
people
to
shoot
themselves
in
the
foot
outside
of
explicitly
enabling
it.
H
I'm
curious
yeah,
so
yeah
jeff,
just
one
out
of
curiosity,
so
if
I
understand
correctly
all
star
today
does
something
like
you
know:
if
a
branch
protection
setting
is
off
what
it
needs
to
be,
it
can
kind
of,
you
know,
fix
it
for
you.
Do
you
think
it
makes
sense
for
this
to
be
something
like
that,
because
this
this
is
also
like
a
boolean
setting.
If
I'm
not
wrong
so
well,
I
can't.
J
K
It's
a
picture,
it's
not
just
so
yeah.
I
think
the
person
who
started
working
on
it
said
he
can
do
secrets,
but
he
can
also
look
at
whether
ssl
is
enabled-
and
I
think,
there's
another
setting
in
the
workforce
that
I
don't
remember
about.
He
said
he
can
do
a
check
on
all
of
those.
So
there's
probably
three
things
you
can
shake.
C
And
I'm
sorry,
I
want
to
say
something
right
now
we
should
not
like.
I
know
right
now.
It's
looking
only
at
github,
but
future
these
checks
are
cross-platform.
All
gitlab
also
has
backlogs.
So
if
I
don't
know
if
strategy
is
to
have
all
star
for
kit
lab,
but
if
that's
not
the
case,
adding
to
scorecard
is
another
plus
one,
so
essentially
we
we
will
be
able
to
add
these
features
at
some
point.
E
I
I
I
would
almost
suggest
merging
the
repos
to
to
be
honest
because,
like
it,
almost
it
forces
us
to
collaborate
on
how
each
of
these
components
are
designed,
right
and
and
and
it
kind
of
forces
us
to
make
sure
that
any
path
that
you
choose,
if
you
choose
like
the
you
get
you
know
like,
for
example
like
if
you
have
branch
protection
right,
get
lab,
is
going
to
have
branch
protection
too
right.
So
when
you
write
the
branch
protection,
you
know
logic,
it's
you
know.
I
I
want
you
know.
E
Like
the
you
know,
branch
protection
is
maybe
you
know
some
something
is
the
interface
right
and
and
there's
a
comp
there's
a
concrete
implementation
of
branch
protection
for
github,
concrete
implementation
of
it
for
gitlab
right,
not
saying
that
we
have
to
to
merge
the
repos,
but
it
it
does
force
us
to
look
at
the
same
things
as
we're
doing
releases.
H
So
you
should
so
it
should
be.
It
seems
like
we
are
consensus
on
basically
going
ahead
with
the
book
related
stuff
lauren.
Do
you
want
to
update
the
issue
and
let
carlos
know
that
we
are
okay
with
proceeding
with
it.
J
Well,
I
think
we
need
a
proposal
first
on
how
we're
going
what
the
ux
is
going
to
be
for,
in
general,
different,
like
level
like
different
privileges
of
checks
or
paths
or
whatever.
H
I
I
think,
maybe
the
safe
thing
to
do
is
we
probably
don't
expose
this
check
in
something
like
scorecard
action
for
now,
because
I
I
think
we
we
are
having
these
discussions
about
you.
Should
we
even
need
a
personal
access
token
in
scorecard
our
channels
up
now,
so
maybe.
J
H
Don't
want
to
have
that
by
default
right
yeah,
so
we
should
probably
start
off
with
not
having
this
check
enabled
in
scorecard
action
by
default,
and
then
once
we
can
figure
out
a
secure
way
of
exposing
it.
We
can
actually
enable
it.
J
E
So
yes
go
ahead,
yes,
so
so
I
would
say
for
the
the
cli
like
we,
we
should
tighten
up
the.
We
should
tighten
up
our
mechanism
for
doing
future
flags
right
because
we
have
we
have
something
for
like.
I,
I
slipped
in
a
v5
one,
even
though
like
there's
nothing
under
it
right
now,
but
we
have
stuff
for
v6.
We
should
decide
if
the
v6
stuff
is
actually
v5
stuff.
We
should
decide
if
enable
serif
like
we.
E
We
can't
say
that
people
aren't
using
serif
because
we
use
the
the
serif
stuff
in
in
the
scorecard
action
by
default
right.
So
we
should,
and-
and
serif
is
currently
future
flagged
like.
If
it
doesn't
need
to
be
future
flag,
then
we
should
say
it's
it's
on
for
the
next
release.
So
that's
that's
one
part
of
it,
but
two
for
things
that
we're
not
sure
about
yet
and
are
strictly
experimental.
E
Call
them
out
like
merge,
merge
the
code
but
say
merge
the
code
but
say
like
hey.
This
is
you
like,
unless
you
enable
you
know
so
like
if
you
think
about
like
cosine
experimental
right,
unless
you
enable
scorecard
experimental
these
things,
won't
work
right
and
defaults.
The
action
to
not
using
scorecard
experimental.
K
Yeah,
that's
what
I
wanted
to
say.
I
think
the
code
is
already
gated
by
a
you
know:
webhook
macro
something
environment
variable,
so
I
think
we
could
having
the
code
in
and
then
just
disable
it
for
everything,
including
the
github
action
and
force
people
to
use
the
environment
variable
to
enable
it.
I
think
it
would
be
a
good
first
step
and
then
I
can
start
thinking
more
about
you
know
failing
early
and
what's
possible
there.
K
H
Cool,
I
think
we
have
two
minutes
over.
I
guess
we
can
end.