Closing the Supply Chain Security Loop with Rust @ Rust Nation UK

I hope you’re good really excited to introduce Steve from jfrog so give him a
big hand take it away Steve cool all right so thanks so much for
coming out to hear my talk my name’s Stephen Chen I run the developer relations team at jfrog I’m also on the
rust Foundation board um and also we’re going to talk a bit about the CD Foundation I’m the chair of
the CD Foundation which is where the Persia project is currently donated to
so um we’re gonna have a lot of fun today I’m going to talk about security vulnerabilities
um pretty broadly because they they affect both the rust ecosystem and also other language communities I’m going to
chat about different approaches for securing the supply chain talk about Persia which is an implementation an
open source project for securing the open source supply chain that’s written entirely in Rust and then we’ll also close it out with
some obligatory chat about blockchain because what would it be at a rest conference without throwing out
um some fun stuff okay so that’ll sound for a good plan you guys are in the right place
okay um so if if you look at what we do as software
developers pretty much most of different applications um the industry average is about 85
percent is open source libraries which are closed source code depends upon so
if you’re not securing your entire system including all the open source libraries then you have a huge
vulnerability in terms of your application stack and in case you know your parents or
your friends or other folks don’t actually know what you do as a software developer well now they do
because we’ve made the headlines as an industry for all of the different software vulnerabilities and attacks on
the software supply chain which have happened recently and this all got kicked off in the mainstream press and
also in our government literature with the solarwinds attacks
um basically this this was an example of a supply chain attack not specific in an open source project this was a closed
Source environment where they hacked into the proprietary Network um that solarwinds used they got into
the CI CD server they were running team City but it could have been any CI CD system that is vulnerable to the same
sort of attacks and right after the software was built and compiled but before it got the final signing with the
solarwind certificates that’s when they injected the malicious code and then Downstream companies which are using
solarwinds software ended up with a vulnerability inside of their firewall and this was discovered by the attackers
actually exfiltrating data and exploiting systems so obviously this is a big issue this started all of the
government legislation in the U.S that the Biden Administration has kicked off nist has a bunch of requirements now for
security of components being sold to the US government wiring software Bill materials requiring software to have
zero well zero known vulnerability is that affected and this has put a big focus on our whole industry on how we
can secure our entire software supply chain but it’s not just this incident there of a whole bunch of different
incidents and actually one of the more recent ones which came out this year was the circle CI breach did you guys hear
about this okay a couple a couple hands up in the room um basically this was a an example of
attackers who got into the circle CI Network they later disclosed how the attack was done basically it was done on
a employee’s laptop which had malware which got in and wasn’t detected by the vulnerability scanners on the laptop
they got a bunch of data off the laptop in particular what allowed them to get
into systems was getting getting the company’s access tokens to get into
internal systems and then from there they pulled a bunch of information off servers since Circle CI encrypts
everything at rest they couldn’t get the data directly off the servers but there was a bunch of in-memory data which had
security tokens and different things which could be exploited those tokens those authentications
tokens were then used to compromise other systems where people had their builds accessing servers and Source
control systems and other systems and it was picked up from that and reports of
those incidents back to Circle CI to figure out how the breach happened and they they fully disclosed what happened
but this if you think about it like compromising a build system which a lot
of Open Source projects use for doing their open source builds a lot of companies use opens up our whole
industry into attacks which could be very bad and I think these incidents are just
kind of the tip of the iceberg in terms of where we’re vulnerable as an industry on security vulnerabilities and I think
this is a great quote from Dan lorenk he’s the creator of six store and also um very vocal about the issues with our
software supply chain every time you pip install gogate or Maven fetch something you’re doing the
equivalent of plugging a thumb drive you found on the sidewalk into your production server
so this is this is obviously bad and we want to make sure that a software developers were leveraging
um secure libraries we’re building on top of a solid foundation but which
anybody trust one of these systems so npm rubygems okay anyone use crates
hopefully most people raise their hands um and like we we have an implicit Trust
on the central repositories on the places which we get open source libraries because we were pulling down
dependencies we’re pulling down different packages and not all of these systems were built
with a Security First Focus so I’m going to talk about different security vulnerabilities which have happened in
all these systems then I’ll do a comparison of different vulnerabilities across the entire Central repository
ecosystem which was done by our security research team
um so for the rest Foundation security is a very big focus and I I think this is important to highlight that the the
rust Foundation the rust Community is making big investments in terms of securing the supply system
um this was a press release by the rust foundation in terms of partnering with openssf and the alpha Mega project to
get funding for securing the rusty ecosystem also jfrog was part of this so
our security research team is helping to assist and find vulnerabilities which I’m going to talk about and I think this
is a critical part to securing the open source ecosystem is you need companies you need foundations you need developers
who are investing their time and energy to fines to uh to fix and to patch
software vulnerabilities which affect the entire ecosystem and jfrog is one of the companies which
is helping out about this so we have a specific initiative to help secure the
rust ecosystem and work both our security research team is reporting and collaborating with the
rust research team and security team on issues we find and also trying to help
secure and make the entire open source ecosystem a better place one example of a a big compromise which
happens um in central repositories is the dependency confusion attack
and um I think this this came out a couple years ago is identified by Alex Pearson but it shows an important lesson
on what happens if you if you put your trust in the wrong place basically what he was able to do was to exfiltrate data
from inside of large corporate networks he targeted Facebook Apple Microsoft and
a whole bunch of other big companies and um this is how you would get data out of the network right so he would use a DNS
spoofed attack to exfiltrate data using a custom DNS server so his his
exfiltration couldn’t easily get picked up but I think the interesting part of his attack is how he actually got into
the systems and so what he was doing is he was in this case he was targeting npm and how
the node package manager works and um one of the one of the attributes of
npm is when every time you make a request against npm
um it’s done in plain text and you can actually pull out some of the dependencies which people are requesting
from the central repository so he was able to pull out um in the case where companies were not
properly masquerading what internal packages they’re using he could pull out what your internal packages were by
intercepting traffic to npm and then what he would do is he would use this to
then publish packages with the same name into npm but with a higher version
number so basically if you had a vulnerable package manager if you were
just kind of going out and trying to get the latest version of your library rather than getting the internal version
of your library which is an older version it would go and see ah there’s a newer version npm and I’m going to
retrieve that now obviously this is this is not what you want to happen because
you know that it’s an internal package that you shouldn’t be retrieving it from an open source repository bad things
happen when when you let kitties touch big red buttons and this can be solved
by putting a a layer in between which actually knows to direct the internal packages to your local repositories and
your external packages to a um an external repository like npm artifactory
our package manager is one example of a product which does this but if you’re using any modern package management
system it insulates you from this sort of attack but if you you’re not paying attention to this it’s very easy to fall
prey to things and Alex Pearson made a hundred thirty thousand dollars off of this exploit basically the way he did it
is this was known for a while to be a theoretical exploit um he worked on packaging and actually
proving that he could infiltrate all these companies not doing anything malicious but just doing like a like a
test that would satisfy a bug Bounty and he simultaneously applied to a half
dozen different bug Bounty programs of large companies and together he made quite a large sum as a researcher so if
anyone’s inspired to become a security researcher and you know make some extra money on the side this is a great
example of of how you can do it and how you can be a white hack hacker a white hat a hacker and actually do this but um
I think it’s also a good lesson for us in terms of like being very careful about where you’re pulling your dependencies and and how you’re um
pulling things in okay so another good example of an ecosystem which is vulnerable is python
um so as you guys know Pi Pi is the central repository for python pip is the
command line tool which you use to pull down packages from it and it’s quite open to adding a new module to Pi Pi
um so we our security research team went and um looked at Pi Pi as an environment
to to test and see what would happen one of our researchers svetter
actually is um he’s he’s a he likes to play ping pong he’s one of our Israeli
security researchers and he posted a package Federer 0.8 does anyone want to
guess what sveter does on his package when you run it
okay so it’s it’s it’s a very complex algorithm
he opens his website so it’ll open his personal blog and this
is an example of you can pretty much publish anything you want to Pie by and it’s not checked by anybody it’s it’s
allowed to post different packages it’s very open now sweater is a nice guy he’s a white hack attacker but what if you
posted something which was potentially malicious so we ran a security scanner on the
whole database of packages submitted to python initially got 300 000 hits on
things which were potentially malicious like using an eval with a constant input so that’s like a big obfuscated code
block that is trying to be executed trying to read and write sensitive files like slash Etsy slash password spawning
a command shell pipe to a network socket or executing arbitrary strings from the network as code so any of those things
are potentially suspects there could be a legitimate reason why a application would want to do that initially we got 6
000 hits of the 300 000 packages that we ran on this and one of them was noblesse
so this optimizes your PC for python or should we we all want our PC optimized
actually it exfiltrates data through Discord so it would it would pull data off your computer and push it out via
Discord messages Pi tag aura making Pythagorean theorem
easy and this would execute arbitrary python code restores that’s a string from a C2
Network so um this shows you a couple examples of
um exploits the other interesting thing about Python and npm is they have um
hook switch run on package install so you don’t even need to run the library or run your code to trigger these
exploits all you need to do is have it as a dependency that’s pulled in and then once it’s downloaded it’ll run the
package hook and immediately exploit the code the way they would get information off your computer is normally your browser
passwords are well well secured right so you know web applications and things
running in the browser can’t access your passwords that’s all protected from them now unfortunately a Python program
running as as you as the user is not well protected from getting this data
and it’s quite easy to Simply um call Krypton protect data get access
to the hall password database of all your passwords on a local environment and then send them back out via Discord
or some other exfiltration mean and this is just a simple sqlite database you can access it you can pull a bunch of
usernames and passwords and then use these to later pull exploits so this is
the actual code from one of the Python packages which we found we reported and
has since been pulled off of Pi Pi but basically it’s a it’s a credit card stealer
and um you can see that the code once it’s uninfuscated is is fairly simple so it’s
it’s basically doing what we talked about um to get access to your vaults you
which is the sqlite database and then send it back out um to the network so
um very easy for folks to exfiltrate data now there’s a whole other class of attacks and um this falls into the
general theme of typo squatting um so it’s very easy or very common like
developers make typing mistakes and package names or you forget the namespace on a package and one example
of this is in npm we found a whole bunch of packages
um for the Azure ecosystem where duplicate packages were created but just without the namespace
so this is really bad and if you accidentally left the Azure namespace off then you’re gonna be pulling down
the malicious package instead of the package you actually wanted to get
um they also additionally created an automation which would create a bunch of users
so that every single package was uploaded by a different fake user so you couldn’t even see like ah this user has
created like hundreds of malicious packages they’re all bad um actually each one was a randomly
generated person who uploaded and they uploaded 218 different packages
um in at Azure at Azure test that is your tools and add catalang and use this
to exfiltrate personal information from developer machines okay so all this is really bad so far
right this is stuff we don’t want to repeat um now one of the things which we did really recently is we looked across all
the different package ecosystems at exposed secrets and Central repositories and I think this is a good
indication of like how good we are as open source developers about maintaining Goods security hygiene
now the these numbers are bad so
um Docker was the most egregious of the ecosystems we found 5.78 million exposed
secrets and a lot of these were in the um
um the layer files some of them were in the in the um the docker files as well
um we did find some in crates IO so about a hundred and ten thousand we
found some in ruby gems in Pi Pi and also npm um but I think the most egregious if you
look at this was definitely a Docker ecosystem so what what can we do as open source developers to prevent this from
happening so there’s there’s some easy steps to make sure that you’re not exposing secrets in code and this
applies whether you’re doing open source development or if you’re doing your own commercial development to prevent making those mistakes
so first one is use some automation to check for Secrets exposures this is what the bad guys are doing
right they’re not they’re not going and manually checking for exposed Secrets they have tools they’re running through repositories they’re looking for exposed
secrets and then they’re exploiting them at Mass um so there you can do this by running different security tools on your code
base at jfrog we have a commercial one jfrog x-ray which will do this and tell you if you have any exposed Secrets as
part of our new Advanced security a really good open open source alternative is truffle hog
this is an open source project you give it your um your repository and it will scan through and see if you have any
potentially exposed secrets and then you can figure out any mitigation strategies which you might want to take on your um
on your Repository so number two is
um concentrate generating tokens with broad permissions that never expire so it’s really really common for open
source projects to um a to issue tokens which don’t have an
expiration date so that’s really challenging because you you need to go to the um the system and actually
manually rotate and expire things when you want to or to Grant more permissions
than it needs and it’s it’s really easy to set the permissions more granular if
you’re doing this in in GitHub or other systems but we found that about a
quarter of the tokens which we identified were given admin privileges which is way more permissive than you
actually need for most of the operations that people were accessing so this is number two make sure that you generate
tokens with the smallest permissions it needs and also set of reasonable expiration so if somebody gets access to
it that they have a limited time window to actually do something with it mistake number three is no access
moderation for the secret so here are some examples of people
putting secrets and environment variables and this is really challenging because it’s hard to manage these it’s
hard to take care of these you can use a vault like kubernetes secrets for kubernetes based applications Docker
Secrets if you’re using Docker swarm um requiring the user to supply a secret as a Docker run argument or using
hashicor Vault any of these will give you better management of your secrets it’ll tell you that your secrets should
be rotated or it will allow you have a central place where you can manage and make sure that the secrets are not being
exposed so this also will help you better manage the secrets in your application
number four is fixing a leak by unpublishing the token so if you have a security that’s leaked
in your git repository and if you later have a commit which deletes that token that doesn’t
actually fix the problem and we we found a bunch of instances where people had fixed leaked security tokens by simply
like removing them in a later commit and anybody can just pull the history and get the original token out so you
haven’t actually fixed anything so this again is a is a bad practice and if you
ever have a security token that is compromised you actually need to to rotate it to make sure the compromise
systems um
okay so the question is could you could you do rebasing to to remove it from history now you you could do that
um doing rebasting and modifying history is dangerous when you have like a lot of people working on a project together
um but it also doesn’t guarantee somebody doesn’t have a version of it from before you rebased so it’s still
you should rotate the token not just try to fix it that way okay so that’s mistake number four
mistake number five is exposing unnecessary assets publicly
one of the examples we found was um an entire test repository which was
published accidentally to Docker hub um it had a bunch of exposed secrets in
it and again like this problem could have been solved by simply not publishing stuff which shouldn’t have
been published in the first place so again um you know only only make sure you’re only publishing your production code and
stuff which you want people to download not internal things which shouldn’t be published okay and when we look at the rust
ecosystem so I mentioned that there were there were a lot of packages which had exposed Secrets but the really good news
about this is that only one of these was active so when we looked at like like active
versus inactive tokens we could only find one in creates.io which actually
was still an active exposed secret and I think for for any ecosystem in central
repository this is a really good sign that rust developers care about security they’re they’re doing things like
managing their secrets and making sure that they inactivate things making sure they don’t expose secrets too much and
this is really really good compared to the rest of the um package ecosystems which we checked
okay so um all of this and more you can find out at
research.jfrog.com this is where our security team posts all their research and findings
um and they they post kind of different exploits and zero day um activities which they research and of
course this is also available in our security database so I’m going to talk a bit about Persia
now and what Persia is is this is an open source project
that was started at jfrog we’ve now opened this up to the public so that
anybody can can use it it’s part of the CD foundation so it’s a vendor neutral
Foundation that is doing this in collaboration with other companies and we we think this is a really good
forward-looking take on what what you would build if you were starting and
building open source package distribution from the ground up um so I think that um the name of Persia
also was chosen to be a nice reference to Greek mythology so the Greek origins of Persia are that
um back in in ancient Greek um time frame they would communicate
over long distances using an array of torches so they had two sets of five torches
these corresponded to the Greek alphabet so when you’re communicating over like
mountaintops and long distances for for war purposes or for a message communication you had a reliable way of
doing this and I think with Persia what we’re trying to build is we’re trying to build a reliable fault tolerant and
secure way for us to communicate and distribute open source libraries and open source packages
um Percy has ridden entirely in Rust um so I I think that when we looked at
this project and we started working on it we’d done a bunch of projects at jfrog in in golang we’d also had a lot
of experience with coding and and obviously JavaScript and Java and other Technologies but for this project we
decided that the right language choice would be rust and some of the reasons why we chose rust as a language
are these reasons and I think it’s a lot of the reasons why we’re all here and why we’re using rest technology in our
companies and on our personal projects but for anything which is focused on
security one of the important things is that you’re using a language which allows you to write code which is secure
and and forces memory safety um it’s really really easy to have
memory safety issues that creep into your code base um without you actually intending for
that to happen um and by having a language with a friendly compiler which actually gives
you a lot of information and helps you to solve issues before they get into production that helps ensure that you’re
releasing software which is secure Russ does great documentation and tooling so it was easy for developers in
our team who weren’t originally rust developers to get up to speed to engage with the community
is all open source as well so that’s also important because we’re building on top of a foundation we want to build on
an open source project and not be depending upon proprietary code which may or may not have vulnerabilities or
issues and Perseus designed to be run on client machines on on desktops on CI CD servers
on cloud infrastructure so it’s also really important that it’s fast and I think this is something which we
we could get for example memory safety open source and a lot of these other and other language communities but we
wouldn’t get the raw performance and the experience we were looking for without depending upon something which which was
really performant um when you look at the software supply chain problem we’re trying to solve this
is a diagram from the salsa project which is part of openssf openssf is the
open source security Foundation we’re also a member of that and when you look
at it they basically categorize security risks into these
eight different categories and um what we’re trying to do in Percy is
we’re trying to not solve all of this but solve six out of eight of the
problems here so when you start here as a developer you could have a security exploit which happens because a code
review gets bypassed or the source control system is compromised we can’t help as much there but then once you’re
actually doing things after Source control so if somebody tries to modify the source
control later we talked about rebasing that’s a great example of changing history and altering what’s in Source
Control Systems you can have a compromise build platform you could be using a bad dependency
um bypassing CI CD the solarwinds case was an example of for example a CI CD
exploit where they actually had a compromised cicd system you could have a compromised package
repository or you could be using a bad package and the basic security guarantee that we have with Persia is if you
download something off the Persia Network it will be the same binary which you would get if you if you
built from Source yourself or if you got it from The Source repository for yourself
what we’re trying to do is build something which is reliable so one of the things is to make sure
that it’s always up it’s always available that it’s it’s um provides the sort of infrastructure which the open
source Community can rely upon for their daily development for builds and even for company company use that it’s secure
so this is something also that I think a lot of the central repositories were not built from the ground up to do which is
to provide a very very high level of security and your your essential repository is
also only as good as your CI CD system so for example if you’re taking builds which are built on
on Circle Ci or if you’re taking bills that come out of GitHub or even developer machines those could all be
compromised and the last one is open so making sure that the entire Source
base for the project is entirely open source can be verified and you know exactly what’s running on the central
servers which you depend upon and this also is something which get builds that trust and allows you to trust in the
implementation so um let me let me go through the different parts of Persia I’ll get into
some more detail on the implementation and um just just like our our friend in the
front row this is an open session so feel free to shout out and ask questions at any time you don’t have to wait till
the the end of the presentation if you have something which is a burning question okay so there’s basically like three
primary components and things which we’re doing with Persia um the first one is distribution of Open
Source artifacts and for this we’re using a peer-to-peer Network where all
the nodes are sharing the dependencies which they have downloaded
um the top ones the authorized package Registries those are ones which are run
by companies which are supporting this project in the CD Foundation they have a
superset of all the different packages available on the network and you can you can download off them but again it’s
it’s um we want you to get it from the global Network every time you run a CI CD
server or you run Percy on your laptop or you run it in a different instance you’re not doing all of the things which
the authorized nodes are doing but you are participating in this peer-to-peer Network and re-sharing libraries which
you’ve downloaded so what this means is that for for recent libraries for things which you’ve
downloaded um things which are being downloaded a lot you’re going to get very good
performance because you’ll have lots of nodes and lots of people which are using it which can re-share it for older
libraries or things which are less popular you might have fewer nodes or you might have to go to the the authorized package registry to get the
um the network but in all cases the uptime of the network is much higher
than if you were depending upon a single Central server and I think we’ve all seen cases where the the uptime and the
availability of central repositories goes down it’s just like a denial of
service attack on the whole developer ecosystem because we we wake up in the morning and we try to compile our code
and suddenly it won’t work because we can’t resolve dependencies npm used to have lots of availability
issues until Microsoft bought it and it’s gotten a lot better but they still have monthly outages for a couple hours
so it’s it still is an issue if you rely entirely on the central Repository
the second part of Persia which um I think this is one of the things which distinguishes US from other approaches
to this is the multi-node verification of builds so every time we add a new package to
the repository what we do is we have all of the authorized nodes both build that package
um get it ready for publishing on the network and then compare it with other um authorized nodes to make sure it’s
the same package and only if it matches and it passes consensus then it gets
published to the network and I think um this gives a much higher security guarantee than depending upon a single a
single vendor or a single implementation so we have different companies participating this including
jfrog and Oracle future way deploy Hub
and docker we’re all running instances of the hardware and you know verifying
builds against each other and as the network grows as more companies participate and more users participate
this gives you a very high guarantee that for example if the jfrog instance got compromised nobody could publish a
malicious package to the network it would have to be something where they would compromise the majority of the
network and the last component of Persia which completes this is the immutable
transparency Ledger and this is the record of all the verified transactions on the network
it’s designed so that you can validate all the transactions when you down load
something off the network you can make sure that what you download is exactly what was published the signatures match
you get this gives you the provenance information about the packages which are being distributed
over the perseid network and without um without being one of the authorized
nodes and achieving consensus on updates to the block to the immutable transparency Ledger you can’t make
changes to this so this this sounds a lot like blockchain right what was your question
okay okay so the question was what if most of the authorized nodes get compromised
um so what we’re using for this implementation is we’re actually under the covers we’re
using a blockchain library called the left bft and the basic guarantee that you get
with their consensus algorithm is um if up to a third of the nodes are
compromised there is no performance degradation and you can’t put a bad
transaction on the network um from one third to two-thirds of the nodes like if you if you compromise up
to two-thirds of the nodes but not not two-thirds then you could start slowing
the network down so you’d see a degradation of service once you get above two-thirds of the nodes then you
actually can put a a bad transaction on the network and you could compromise the network
um I think that obviously this sort of attack is possible with maybe a nation-state hacker or if if you know
China went after the Persian Network they could simultaneously compromise like like a lot of servers at once
realistically this is giving you a much higher security guarantee than even depending upon GitHub which is Microsoft
owned and I think we all trust GitHub we trust a bunch of different Services
um where they would be much easier to compromise than compromising multiple different corporate run instances of
this but that’s that’s a good question
okay so the question the question is because this is a ledger you can’t roll back transactions so how do we handle
things like for example if a bad package got published and that that will be done
by an update not by a rollback right so you what you do is you publish a new
transaction which says this this previously published artifact is invalid and then that would show up in the next
block which is published on this to to resolve a artifact fully you have to to
walk the full um immutable ledger to make sure that the final state of it
um is done and the architecture diagram for how Percy is built we both keep the the full Ledger
but then we also have a um a database version of it which just shows the final state of all the artifacts where this
has already been walked on your local machine okay question
okay so good good question about what we what we consider to be the same for for builds
um so right now what we consider verified and being the same is is what
you said it’s it’s bid for a bit identical artifacts which are verified by reproducible builds so if if a
artifact is wants to be published on Persia the the kind of the way this works is the
authorized nodes have have build nodes which are running alongside them they will pull down the source code from the
the stated Source repository they will execute the builds um we we have recipes for the builds to
make sure that they’re reproducible and then it’ll compare the hashes of those different builds to make sure that
they’re the same now one of the future areas for research on this is because
we’re running the builds in a similar environment across
um at roughly the same time and then immediately comparing results we believe that there is
um ways which we can verify some builds which are very very hard to make reproducible or make fully reproducible
by doing verification of other things across the build cluster so we haven’t
actually implemented anything which is not a reproducible build yet but we think
okay so that that is good advice um I think the 99 cases reproducible
bills are the right answer but there there are some cases where it’s helpful to be able to verify something which is
mostly reproducible but there are known deviations Okay so
this this looks a lot like a blockchain right and um we we all know that blockchain’s
evil right oh okay cryptocurrency is evil so so but
blockchain’s cryptocurrency right
okay you guys are too smart so um yes that’s exactly the answer so
blockchain is a technology for consensus and it’s it’s it was originally
popularized by cryptocurrency as a use case for it but there’s actually a lot of other use cases for it we think that
immune transparency ledgers are a great use case for blockchain especially where they need to be distributed
and the the evil part of cryptocurrencies is actually the the way it’s applied the way blockchain is
applied to those so for example um I think this was published um as of last November
um Bitcoin was consuming more power than the entire country of the Netherlands
and this is horrific from an environmental standpoint um I mean I we can all of our own
opinions about the value of cryptocurrencies but consuming like a wasting a huge amount of power is is not
something I think any of us really want um and this also is very different than how we
apply um blockchain for the Persia project so the reason why Bitcoin consumes so much
power I think you guys know a little bit about this but it’s a it’s a proof of work algorithm which basically means that you you’re
you’re requiring that the way that you both mine tokens and also verify transactions is by brood computation
power and the fact that getting computation power requires a huge investment of capital mean and it’s
distributed over well hopefully a large number of players this makes it very hard or impossible for somebody to take
over the network because the amount of computing power they would need to subvert the network would exceed what
any single person or hopefully any country could achieve although given the number of Bitcoin servers which were in China
for a while China could have easily taken over the network if they wanted to
um in Persia what we do instead is only the authorized nodes participate in
consensus um so this makes the the set of nodes participating in consensus
um it’s fairly well defined it’s a it’s a relatively small set of nodes so you’re talking on the order of of dozens
of nodes which are participating in the consensus algorithm this makes it a lot faster as well so that the transaction
speed of things happening in the network is much quicker I think Bitcoin
transactions I don’t know what the latest but to complete a full Bitcoin transaction was in the order of minutes
which for financial transactions is crazy although they have other workarounds and ways of people doing
quicker transactions by doing things off chain um but for the purposes of Persia this
is an application which it doesn’t suffer from the same huge resource use energy consumption as um
um Bitcoin does and it gives us the benefits which we talked about for both like reliability so it’s very very hard
to DDOS our Network um and also for um the transaction guarantee so that you
can’t easily compromise the network without compromising a large set of networks the authorized nodes are also the ones which
run the build pipelines so when new things get added to the node we’re not expecting everyone in the network to
spin up a CI CD to like start you know setting up kubernetes and instances to run their own infrastructure we do this
on the authorized nodes and in different Cloud infrastructure we have some in gcp some in Amazon and some in
Huawei is actually planning on spinning it up in in their own cloud data center
as well which is entirely separate so you’re getting a big diversity of of companies a big diversity of cloud
providers and all of this without having a mass explosion and Computing resources which
are required or in the amount of Investments and then when you participate in the
perseid network as an individual or with your company you’re one of those blue nodes you’re
not participating in consensus you’re not participating in the um the builds but what you are doing is you’re helping
with distribution so anything you download off the network by default you can turn this off if you don’t want to re-share but by default you’re
re-sharing um for the peer-to-peer implementation I mentioned we use a left bft which is um
the consensus algorithm for the peer-to-peer implementation we use lit P2P which is
um the underlying peer-to-peer implementation underneath ipfs um we didn’t need the full ipfs stack
and it was it was a little bit too much to start Distributing code artifacts over ipfs but lit P2P is a great Library
very well maintained and we’ve been giving back to the project as well with some improvements for the for the rust
implementation of lip P2P and that’s what you’re writing locally so you’re running a node which re-shares
artifacts which contributing to this this large distribution Network
and only with things you’ve downloaded so you’re not like storing a bunch of artifacts which you’re not interested in or haven’t been using
um so this as I mentioned this is a large package distribution Network
um jfrog Docker deploy Hub Huawei future Wayne Oracle or contributing to this but anyone else is welcome to join and can
contribute to this you don’t have to be a member of the CD Foundation to contribute to the project but that’s the
umbrella organization which the Project’s under right now and um I think that it’s a it’s a good
opportunity to get in early on an open source initiative which is entirely rust-based which is for the good of the
community and hopefully which will change the way which we think about security as a um an overall industry
now this is a rough architecture picture of of how Persia looks so you can see
that we have our runtime Library that’s running locally we have artifact storage and retrieval the source to Binary
builds is is separate but that allows us to run builds and do the verification of them
the Persia command line interface allows you to interact with it we also have
plugins and Integrations for different language ecosystems right now we have
implementations for Docker so you can pull and use Docker images for Maven and
Gradle for the Java ecosystem um we are planning also to implement go npm Conan which is a CNC plus plus
package manager and cargo so if anyone’s interested to help us with getting the
cargo implementation which should be fairly straightforward since everything is source-based that would be awesome as
well I think it would be a great way to to dog food the project and actually get Persia using Persia dependencies that
are validated on the perseid network we also have a new plug-in for Percy as well for visual code that we um just had
an early access release of one of the developers implemented that and you can use that to both run a Persia node right
from Visual Studio code and also to see which dependencies are coming from
Persia other essential repositories and replace things with a Persia verified image
this is a architecture diagram of Persia and one of the things which we
specifically architected was keeping the the build pipeline separate from the Persia node itself
um we were trying to avoid attacks on the Persia Network where a compromised
build pipeline would cause the node and the entire blockchain to get compromised
basically you could potentially exploit the network by publishing a library with
code that runs in the build and then compromising the build server from the running build and then getting back into
the node so this is why we have like a strict separation between the persea node and the Persia build Pipeline and
we’re just giving the results from the build pipeline back to the Persia authorized node but it has no way of actually executing code or doing
anything to the to the perseid node on the person node itself
um so we have our artifact service and our local artifact storage which handle
all the different libraries which were Distributing the Tran we have both uh
the blockchain and the blockchain storage so that’s the raw Ledger and also a transparency log service on
running on top of that so the transparency log service is much easier to query and get information rather than
walking the whole blockchain but when you first start up the service it will download the the mutable transaction
Ledger off of the Network store it locally and then create the transparency log which you can then use to look up
transactions on the network so everything you’re pulling off the person Network you’re actually validating
locally to make sure that it’s exactly what you expected um like I mentioned all this is using live peer-to-peer for the PDP for the
communication instance we have a verification service which verifies the
artifacts you downloaded against the transparency Ledger um the authorized nodes also run the
build service um and this gives you kind of like the high level architecture of what we’ve
built out with the Persia project okay so where can I find Persia
so question yeah yeah let me go back a slide
okay so all right so the question is is is the output
um executables or or Docker images
okay so it depends on on which language you’re pulling from so in the case of
Docker the the output is is a Docker image in the case of java we’re outputting
jars or or runnable files in the case of rust we we’d be giving you
um cargo that you and crates that you could use
um and for building um anything which is
um platform dependent we have to build for every architecture and with the with the common Flags
um so another project which we run at jfrog is um Conan which is a CNC plus
plus package manager and we we also run Conan Center which is a central repository for Conan and as an example
for for Conan we have recipes which map to different architectures
and we run it on both um you know Linux based architectures we
have Max Stadium outputting Apple based architectures and we distribute the same
library but for multiple different architectures and this is the same sort of system where everything’s being built
on network so it’s the responsibility of the authorized knows to set up and provision
the infrastructure which allows us to publish for different architectures now that said
we’re going to publish for different architectures but we’re not going to publish all the different possible like build flags or options which you might
want for your own like corporate or or project use so if you want to do
something which deviates from kind of standard options and things which we provide you would have to build from a
source yourselves and since this is an open source project you could potentially you know set up the person
to build Pipeline and use that as a as a a way of building the open source
project yourself yes
okay so the quite the the question is like let’s say I’m super interested in I
don’t know let’s say r as a language and I want I want Persia to just start like building and
distributing stuff for the our ecosystem so the way you would do that is you you’d
work with us to build a persea integration for the r language
um what we try to do for each ecosystem we support is to provide as
seamless integration with the existing build tools and infrastructure as possible so for example for Docker we
integrate with the docker command line you can just use standard Docker commands and then it spins up a proxy
like a local proxy which looks like Docker Hub and then you can you can redirect the request to that but that’s
actually pulling off the persea network we do something similar for Maven and Gradle and the goal for supporting a new
language ecosystem is if I’m a developer Who develops in that language ecosystem it should be an easy command line or
configuration change so that I go from how I’m developing today to pulling
stuff off the persea network and if once we get the new Persia integration
completed then we would add it in to the um
the set of packages which we’re building on the build pipelines for the machines which are running
again like the way we’re doing this is we’re only building things which are in
a curated set of packages and things which folks have identified like this is
the right build script this is the right Source repository this is the ownership of it
um currently the way we’re doing it is we have a GitHub repository set up where people can contribute to it they can
submit new recipes and new things which should be built on Persia so again like for your new ecosystem you would add in
the the r projects which you think should be built by Persia submit a PR so
that we would start adding that to the set of repositories we’re building and then all of the build nodes would then
start building these and then make it accessible to users from the r community
I asked or it’s meant to ask which is obviously that involves a committee of
resources
it might usually happened that I wanted to do something
okay so all right so let me expand the answer a little bit so I’ll ask it again
and then I’ll answer it because I think it’s it’s hard sometimes hard to hear without the mic okay so basically the expanded question
was hey that’s great I can add support for a new language but then what if I can’t
convince everybody on the perseid network that they want to build that because it’s it’s too much it’s too
complicated it’s too expensive but then I want to fund it I want to set up a build node to run it
so one of the things we’ve discussed we haven’t implemented yet is
um sorry I’m going the wrong way so we have this set of companies running build nodes and it’s possible that like
maybe a subset of these they they care about a language Community or about a build system but the rest of the world
doesn’t and they want to they want to then go run and support that ecosystem so um one of the things we’ve discussed
is the possibility of the authorized nodes selecting what technologies that they
want to build for or it could be like what what a specific architecture maybe like only a subset of the the authorized
nodes care about arm 64 builds and they’re the only ones
which are actually going to provision like hard work to support those types of builds now the to achieve consensus
you need at least three nodes which will agree to do the builds do the
verification and then that gives you consensus on the network for purposes of authorizing transactions
um so that would be the minimum we might set a larger threshold just for security reasons if we believe that 3 is not a
higher enough security barrier um but in your case what you could do then is you could say hey I really care
about X language Community it’s now implemented where it’s possible to build a perseid network you could set up your
own infrastructure by joining the project and saying I’m going to set up my own Percy authorized node all I want
to build is this new language and I have a couple friends maybe like to find two other companies which would also build
that language community and you’re good to go okay an excellent question actually all
the questions have been really good so far so you guys you guys are an awesome audience so where can I find Persia so um we have
a great website persia.io that you can go to to check out and find a little bit more about the project we tried our best
to document it to be very open about the architecture and what we’re doing so this is the place where you can go for
everything Persia we also have a very active slack Channel
so this is part of the continuous delivery Foundation project you can join the CD Foundation slack join the Persia
Channel and get involved in the conversation exactly the sort of questions you’ve been asking here are
like this is what you want to ask on the Perseus slack channel to find out more so I’d recommend joining that if you’re
interested to to hack on the project obviously we have an open GitHub repost at github.com Persia you can find the
entire code base which we’ve been building and we’ve been talking about and I hope that you’ve learned a little
bit in this presentation about Persia about the future of supply chain security
hopefully I’ve inspired you to either give the project a try or to be a
contributor and I want to thank everybody for coming to the session and asking
wonderful questions so thank you all
okay and one other big ask is we we actually have a bunch of the panelists for the upcoming rust Foundation session
which starts very shortly so um join me back Josh and all the other panelists
and you can hear more about the rust Foundation which is also I think a big part of the rust community and what
makes it great to be a rust developer so thank you all