►
From YouTube: Jun 8, 2023 - Ortelius Architecture Meeting
Description
Steve gave an update on the #Guac integration, work on #Emporous, and the new #CNCF Artifact working group that Alex Flom will be chairing. He also reminded everyone that there was a joint meeting with Fidelity around the ‘evidence store’ concept.
A
B
B
B
B
We
trace
and
I
did
meet
with
the
cncf
working
group.
For
the
oci
Registries,
so
that
was
out
there
with
Andy
Alex.
Was
there
Chan
I
can't
remember
if
cat
was
there
or
not
I,
don't
think
cat
was
there,
but
basically
looking
at
what
needs
to
be
done
on
the
oci
registry
side
for
supporting
any
type
of
object
and
adding
the
search
capabilities
into
that.
B
So
that's
happening
on
that
front.
On
the
Persia
front,
Sasha
I'll,
as
soon
as
I
find
out
the
invite
for
that
I
will
send
you
the
invite
for
the
governing
board
thing.
It's
gonna
be
on
a
Friday
but
I
as
soon
as
I
find
out
from
Stephen
chin.
When
he's
planning
to
have
that
meeting.
I
will
get
that
off
to
you
on
the
Percy
front.
B
B
C
B
B
So,
if
you're
able
to
go
and
fix
one
package
in
your
in
your
application,
which
one
it
would
it
be
and
if,
when
you
do
that,
you
know
what
is
you
know,
it's
going
to
cut
your
you
know.
You
have
a
hundred
vulnerabilities
and
now
you
go
down
to
five
just
by
replacing
or
updating
one
package
so
that
type
of
data.
B
B
B
The
guac
team,
basically
we
met
with
them
and
what
they
are
doing
is
taking
s-bombs
all
the
dependencies
and
s-bombs
and
doing
like
a
dependency
tree
graph
and
allowing
you
to
navigate
through
it.
So
one
of
the
things
in
artillius
that
we
don't
quite
do
yet
is
being
able
to
look
at
dependencies
of
dependencies
at
the
package
level.
We
take
the
initial
s-bomb,
that's
there
and
just
that's
kind
of
like
where
we
stop.
B
You
know
running
some
model
against
the
data
all
the
way
through
the
guac
data
as
well
to
figure
out
that
bang
for
your
buck.
So
we
can
tell
people.
This
is
what
you
need
to
go
fix,
and
this
is
how
long
we
expect
it
to
take,
and
this
is
going
to
be
a
return
type
of
scenario,
so
fun
stuff,
a
lot
of
moving
pieces.
A
Yeah
so,
while
like
refactoring
few
pieces
right
so
like
since
I'm
new
on
golang,
so
what
happened
like
like
I,
have
I
wrote
like
all
these
code
in
main
project,
okay
main
packages
and
when
I
was
refactoring,
so
I'm
facing
few
few
issues
there.
So
the
objects
are
not
referenced
properly,
due
to
some
reason
so
I'm.
Looking
at
those
the
other
issue
that
I
faced
was
so
right
now,
like
I,
have
implemented
nft
storage,
but
there
is
also
need
for
leisure
right.
Yes,.
A
Yeah
and
there
is
like
no
SDK
provided
by
xrpl
yet
for
like
golang,
so
I
was
looking
at
the.
That
is
the
tough
part.
Actually
I
was
looking
at
like
what
alternatives.
Are
there
but
looks
like
we?
We
can
use
the
python
package
itself
because,
like
golang,
can
internally
support
python
as
well
right,
okay,
but
I,
don't
know
what
will
be,
like
implication
of
that
on
the
performance
or
other
things.
B
A
B
Yeah
yeah
exactly
so,
it
doesn't
necessarily
have
to
be
Atomic,
but
what
we
need
to
be
able
to
do
is,
like
you
said
last
time,
there's
gonna
be
a
lag
that
like
nft
storage,
may
be
down
for
a
couple
days
and
that
we
may
need
to
have
a
job
that
runs
like
every
half
hour.
That
goes
and
does
like
a
synchronized
or
if
we
go
to
put
things
into.
A
A
Like
how
yeah
that
makes
sense,
but
like
how
we
correlate
the
data
that
will
give
us
the
answer
right
like
like,
if
we
are
correcting
data
with
the
build
ID
or
some
other
processes
or
something
job
or
something
so
we'll
have
to
correlate
like
what
all
transactions
occurred.
As
part
of
that
build
right,.
A
B
D
B
A
A
A
B
B
B
We
had
a
separate
repo
I
think
what
we
should
create
is
like
a
tools
repo,
because
we're
going
to
have
other
things
that
we
want
like
I,
have
like
a
depend
about
script.
Arvin
has
his
dependent
Bots
script.
Sasha
has
some
I'm
sure
Sasha
has
a
few
helper
scripts
as
well
that
we
should
start
collecting
and
kind
of
layout
in
like
a
tools
repo
and
though
these
reusable
workflows,
I
think
would
be
a
good
place
to
put
into
the
tools
repo.
B
C
C
We
have
Vincent
Dannon
from
Red
Hat,
who
was
the
one
who
introduced
us
to
emporis.
We
have
garima
bajpai,
who
has
been
part
of
our
group
from
the
very
beginning,
so
I'm
super
happy
that
she
stepped
up.
Steve
will
be
there
and
then
Andy
Gardner
from
the
captain.
Folks
who
works
at
dynatrace,
so
I
think
we
have
a
really
good
team.
C
B
Awesome,
that's
gonna,
be
it's
gonna,
be
interesting,
and
if
and
like
we
keep
going,
the
more
we
find
from
other
other
working
groups
and
other
end
users
like
the
Fidelity
stuff,
the
more
things
that
we
can
collect
on.
What
we
need
to
do
definitely
helps
us,
get
get
more
focused
and
have
a
good
solution
that
can
be
well-rounded
for
people
to
use.
A
D
B
D
B
B
C
B
B
C
C
We
will
need
to
do
some
more
calls
with
them,
though,
so
you
know
the
I
think
that
once
we
have
a
a
connection
to
their
dependency
graphs
and
we're
displaying
it
at
minimum
at
a
component
level
and
maybe
bringing
some
of
that
like
a
just
a
dependency
list
up
to
the
application
Level
and
on
packages
in
some
way,
we
need
to
really
think
through
that.
If
we
could
get
that
done,
then
we
could
show
them
what
we're
doing
and
I
think
they
may
give
up
on
trying
to
build
that
s-bomb.
B
Yeah,
so
to
answer
your
question:
Sasha
is
there
interface
that
they've
developed
is
a
graphql,
so
graphql
is
like
a
hybrid
API
type
of
thing,
so
I
believe
GitHub
uses
graphql
as
its
currently
query
language
as
well.
So
basically,
what
you're
going
to
need
to
do
is
query
their
database
using
their
graphql
endpoints
foreign.
A
B
B
B
B
And
then,
once
we
figure
out
kind
of
the
format
of
the
data
that
we're
getting
back
from
guac,
then
we
can
figure
out
how
we
want
to
link
that,
together
into
our
UI,
whether
it's
just
going
to
be
a
list
like
Tracy
said
or
if
we're
actually
going
to
do
some
graphing
with
it.
The
graphs
that
they're
showing
in
their
in
their
demo
are
this
viz
GS
graphs
of
heart
Google
tree
nodes.
So
it's
not
anything,
not
anything.
We
haven't
done
before
so.
C
Know
the
data
helps
because
then
you
can
query
the
data
and
you
can
do
something
with
that
data,
but
it
has.
The
data
has
to
be
based
on
version,
so
the
graphs
are
cool
looking
and
we
can
certainly
bring
them
in
for
the
wow
factor,
but
I
feel
like
the
the
dependency
data
is
what
Saul
was
talking
about
in
terms
of,
and
we
already
have
some
of
that,
because
we
have
the
s-bombs
right
so
pulling
in
the
graphs
is
just
it
does
help
us
with
the
wow
factor.
B
D
C
B
B
B
D
B
B
B
And-
and
the
other
weird
thing
is
that
I
learned
when
I
was
implementing
our
you
know
translating
our
stuff
from
python
over
to
golang.
Was
you
want
to
live
by
their
directory
structure
and
how
they
lay
things
out
and
not
try
to
fit
it
into
something
that
you're
used
to
like
a
Java
class
structure,
or
you
know
like
one
of
the
weird
things
that
they
have
is
all
the
tests?
B
All
your
test
cases
are
in
the
same
directory
as
your
source
code,
and
they
say
that's
just
the
way
it
is.
You
don't
have
a
separate
directory
for
test
versus
your
main
code,
so
your
directory
ends
up
with
all
this
stuff
in
it,
but
it's
just
the
way
they
decided
to
implement
things.
If
you
try
to
move
things
around,
you
just
spend
too
much
time
banging
your
hand
against
the
wall.
D
D
B
D
B
And
there's
some
stuff
that
we
have
to
pull
out
of
the
open
ssf
that
what
they're
considering
you
know,
check
boxes
for
being
having
a
secure
supply
chain.
So
we
have
to
go
over
there
and
steal
some
of
their
information
of
what
they
want
to
collect
and
same
thing
with
the
fidelity
thing
finding
out
what
they're
collecting
that
we
may
be
missing
right.