Trust and NuGet

Feb 19, 2013 nuget oss security suggest edit

How can you trust anything you install from NuGet? It’s a simple question, but the answer is complicated. Trust is not some binary value. There are degrees of trust. I trust my friends to warn me before they contact the authorities and maybe suggest a lawyer, but I trust my wife to help me dispose of the body and uphold the conspiracy of silence (Honey, it was in the fine print of our wedding vows in case you’re wondering).

The following are some ideas I’ve been bouncing around with the NuGet team about trust and security since even before I left NuGet. Hopefully they spark some interesting discussions about how to make NuGet a safer place to install packages.

Establish Identity and Authorship

The question “do I trust this package” is not the best question to ask. The more pertinent question is “do I trust the author of this package?”

NuGet doesn’t change how you go about answering this question yet. Whether you found a zip file on some random website or install it via NuGet, you still have to answer the following questions (perhaps unconsciously):

Who is the author?
Is the author trustworthy?
Do I trust that the this software really was written by the author?
Is the author’s means of distributing software tamper resistant and verifiable?

In some cases, the non-NuGet software is signed with a certificate. That helps answer questions 1, 2, and 3. But chances are, you don’t restrict yourself to only using certificate signed libraries. I looked through my own installed Visual Studio Extensions and several were not certificate signed.

NuGet doesn’t yet support package signing, but even if it did, it wouldn’t solve this problem sufficiently. If you want to know more why I think that, read the addendum about package signing at the end of this post.

What most people do in such situations is try to find alternate means to establish identity and authorship:

I look for other sites that link to this package and mention the author.
I look for sites that I already know to be in control of the author (such as a blog or Twitter account) and look for links to the package.
I look for blog posts and tweets from other people I trust mentioning the package and author.

I think NuGet really needs to focus on making this better.

A Better Approach

There isn’t a single solution that will solve the problem. But I do believe a multipronged approach will make it much easier for people to establish the identity and authorship of a package and make an educated decision on whether or not to install any given package.

Piggy back on other verification systems

This first idea is a no-brainer to me. I’m a lazy bastard. If someone else has done the hard work, I’d like to build on what they’ve done.

This is where social media can come into play and have a useful purpose beyond telling the world what you ate for lunch.

For example, suppose you want to install RouteMagic and you see that the package owner is some user named haacked on NuGet. Who is this joker?

Hey! Maybe you happen to know haacked on GitHub! Is that the same guy as this one? You also know a haacked on Twitter and you trust that guy. Can we tie all these identities together?

Well it’d be easy through Oauth. The NuGet gallery could allow me to verify that I am the same person as haacked on GitHub and Twitter by doing an Oauth exchange with those sites. Only the real haacked on Twitter could authenticate as haacked on Twitter.

The more identities I attach to my NuGet account, the more you can trust that identity. It’s unlikely someone will hack both my GitHub and Twitter accounts.

The NuGet Gallery would need to expose these verifications in the UI anywhere I see a package owner, perhaps with little icons.

With Twitter, you could go even further. Twitter has the concept of verified identities. If we trust their process of verification, we could piggyback on that and show a verified icon next to Twitter verified users, adding more weight to your claimed identity.

This would be so easy and cheap to implement and provide a world of benefit for establishing identity.

Build our own verification system

Eventually, I think NuGet might want to consider having its own verification system and NuGet Verified Accounts™. This is much costlier than my previous suggestion to do it right and not simply favor corporations over the little guy.

Honestly, if we implemented the first idea well, I’m not sure this would ever have to happen anytime soon.

Vouching

This idea is inspired by the concept of a Web of Trust with PGP which provides a decentralized approach to establishing the identity of the owner of a public key.

While the previous ideas help establish identity, we still don’t know if we can trust these people. Chances are, if someone has a well established identity they won’t want to smudge their reputation with malware. But what about folks without well established reputations?

We could implement a system of vouching. For example, suppose you trust me and I vouch for ten people. And they in turn vouch for ten people each. That’s a network of 111 potentially trustworthy people. Of course, each degree you move out, the level of trust declines. You probably trust me more than the people I trust. And those people more than the people they trust. And so on.

How do we use this information in NuGet?

It could be as simple as factoring it into sort order. For example, one factor in establishing trust in a package today is looking at the download count of a package. Chances are that a malware library is not going to get ten thousand downloads.

We could also incorporate the level of trust of the package owner into that sort order. For example, show me packages for sending emails in order of trust and download count.

Other attack vectors

So far, I’ve focused on establishing trust in the author of a package. But a package manager system has other attack vectors.

For example, the place where packages are stored could be hacked or the service itself could be hacked.

If Azure Blob storage was hacked, an attacker could swap out packages of trusted authors with untrusted materials. This is a real concern. NuGet.org luckily stores the hash of each package and presents it in the feed. The NuGet client verifies the contents before installing it on the users machine.

However, suppose NuGet.org database was hacked. There is still a level of protection because any hash tampering would be caught by the clients.

An attacker would have to compromise both the Azure Blob Storage and the NuGet.org database.

Or worse, if the attacker compromises the machine that hosts NuGet, then it’s game over as they could corrupt the hashes and run code to pull packages from another location.

Mitigations of this nightmare scenario include having different credentials for Blobs and the database and constant security reviews of the NuGet code base.

Another thing we should consider is storing package hashes in packages.config so that Package Restore could at least verify packages during a restore in this nightmare scenario. But this wouldn’t solve the issue with installing new packages.

PowerShell Scripts

NuGet makes use of PowerShell scripts to perform useful tasks not covered by a typical package.

A lot of folks get worried about this as an attack vector and want a way to disable these scripts. There are definitely bad things that could happen and I’m not opposed to having an option to disable them, but this only gives a false sense of security. It’s security theater.

Why’s that you say? Well a package with only assemblies can still bite you through the use of Module Initializers.

Modules may contain special methods called module initializers to initialize the module itself.

All modules may have a module initializer. This method shall be static, a member of the module, take no parameters, return no value, be marked with rtspecialname and specialname, and be named .cctor.

There are no limitations on what code is permitted in a module initializer. Module initializers are permitted to run and call both managed and unmanaged code.

…

The module’s initializer method is executed at, or sometime before, first access to any types, methods, or data defined in the module

If you’re installing a package, you’re about to run some code with or without PowerShell scripts. The proper mitigation is to stop running your development environment as an administrator and make sure you trust the package author before you install the package.

At least with NuGet, when you install a package it doesn’t require elevation. If you install an MSI, you’d typically have to elevate privileges.

Addendum: Package Signing is not the answer

Every time I talk about NuGet security, someone gets irate and demands that we implement signing immediately as if it were some magic panacea. I’m definitely not against implementing package signing, but let’s be clear. It is a woefully inadequate solution in and of itself and there’s a lot better things we should do first as I’ve already outlined in this post.

The Cost and Ubiquity Problem

Very few people will sign their packages. Ruby Gems supports package signing and I’ve been told the number that take advantage of it is nearly zero. Visual Studio Extensions also supports package signing. Quick, go look at your list of installed extensions. Were any unsigned?

The problem is this, if you require certificate signing, you’ve just created too much friction to create a package and the package manager ecosystem will dry up and die. Requiring signing is just not an option.

The reason is that obtaining and properly signing software with a certificate is a costly proposition by its very nature. A certificate implies that some authority has verified your identity. For that verification to have value, it must be somewhat reliable and thorough. It’s not going to be immediate and easy or bad agents could easily do it.

Package signing is only a good solution if you can guarantee near ubiquity. Otherwise you still need alternative solutions.

The User Interface Problem

Once you allow package signing, you then have the user interface problem. Visual Studio Extensions is an interesting example of this conundrum. You only see that a package is digitally signed after you’ve downloaded and decided to install it. At that point, you tend to be committed already.

Also notice that the message that this package isn’t signed is barely noticeable.

Ok, so it’s not signed. What can I do about it other that probably Install it anyways because I really want this software. The fact that a package was signed didn’t change my behavior in any way.

Visual Studio could put more dire looking warnings, but it would alienate the community of extension authors by doing so. It could require signing, but that would put onerous restrictions on creating packages and would cause the community of signed packages to wither away, leaving only packages sponsored by corporations.

The point here is that even with signed packages, there’s not much it would do for NuGet. Perhaps we could support a mode where it gave a more dire warning or even disallowed unsigned packages, but that’d just be annoying and most people would never use that mode because the selection of packages would be too small.

The only benefit in this case of signing is that if a package did screw something up, you could probably chase down the author if they signed it. But that’s only a benefit if you never install unsigned packages. Since most people won’t sign them, this isn’t really a viable way to live.

Conclusion

Just to be clear. I’m actually in favor of supporting package signing eventually. But I do not support requiring package signing to make it into the NuGet gallery. And I think there are much better approaches we can take first to mitigate the risk of using NuGet before we get to that point.

I worry that implementing signing just gives a false sense of security and we need to consider all the various ways that people can establish trust in packages and package authors.

If you’re interested in more thoughts on this, check out my follow-up post, Why NuGet Package Signing Is Not (Yet) For Me.

Found a typo or mistake in the post? suggest edit

Comments

29 responses

Sterling Smart • February 19th, 2013
I'm pretty lazy myself, so I think piggy-backing is a great idea. However, I have to completely disagree w/ you when it comes to the unlikelihood of someone hacking multiple accounts. The vast majority of people aren't likely to have multiple passwords, so when one account is compromised, you can pretty much consider the rest compromised as well.
Raif • February 19th, 2013
Hi, i made some inflammatory comment on nuget a while back, probably discrediting my self, none the less my issue with nuget is one of trust too but an aspect you did not cover.
Let's say im interested in a oss proj, these days more and more people only release compiled code via nuget. So i get the package and next thing i know it has altered my web.config, added a few classes and god knows what else. Elmah does this. Totally benign. Actually a convenience. However, if i want to repeat this installation on an other branch ir proj, i have no idea what was done, or say on qa or prod where i leave the web.config be.
Worse yet what if you try to remove the installation manually and miss stuff, your proj is now got all manner of cruft in it.
I know the short answer is do everything through nuget and everything will be wonderful, and/or only add nuget packs to some test proj till you know what they do.
I would like to know exactly what a nuget pack plans to do and an alternate manual route before i install.
None the less everyone seems to be on board, perhaps i should just drink up.
Arvo Sulakatko • February 19th, 2013
What if you had a way to inspect and analyze every instruction in that assembly. With some reasoning such analysis based on a white, a gray and a black list could tell what that nuget assembly seems to be doing. I am working on something like that.
wwahammy • February 20th, 2013
I don't see how signing gives a false sense of security. Even if a package is signed using an untrusted root (self-signed or the like), signing guarantees the package hasn't been modified after creation. In my book, that's pretty important. The big problem with signing is how freakin' difficult it is to do right now.
haacked • February 20th, 2013
Yeah, you're probably right. I'd hope developers would be less prone to this. Maybe I'm too optimistic. This is why every site that has important information needs 2-factor authentication!
haacked • February 20th, 2013
Did you submit an issue? Having a way to see what changes will be made is interesting. Though honestly, aren't you using source control like Git? The only sure way to know what will change is to see it change and then just revert the changes you don't want. :)
haacked • February 20th, 2013
AKA anti-virus software? I think that's a losing proposition and probably will be less effective than other means to establishing trust. Antivirus software has been shown to suck at detecting _new_ threats. http://www.nytimes.com/2013...
haacked • February 20th, 2013
You don't need to sign a package to determine it hasn't changed. A strong HASH will be just as effective.
Raif • February 20th, 2013
aha, good point about git Phil. I'll buy that. I'm still a bit weirded out about not having my dlls stored where I generally store them, in a Lib folder at the root. I guess if I had greater insight into how packages are created, applied and so on I would be more comfortable. That of course is on me, but it would still be nice if a published package listed what it planned to do.
thx
Mike McG • February 20th, 2013
Although you seem entrenched in opposition of digital signatures, I will argue for it anyway. :) Digital-signing leverages the entire ecosystem and conventions of x.509 PKI. Publishers are accustomed to it (publishing to app stores, using ssh/github, securing http connections), and while signing certificates is not (always) free, they aren't outrageously expensive (free for email assurance, or $50-$100 for identity/organization assurance). People are also accustomed to chains of trust, moreso than webs of trust when it comes to computing. We encounter PKI-based trust UIs all the time, e.g. browser address bars, ClickOnce/JAWS, and MSI installs. Regardless, package signing shouldn't be "required". The UI issue remains but is not insurmountable: e.g. NuGet could locally verify the package certificate against locally-trusted authorities, and annotate package names with "Email Verified", "Email and Identity Verified" or "Email, Identity and Organization Verfied" (or a "verification failed" message).

Relying only on social networks ignores that this isn't what those services were intended for. Security practices with social network accounts are laxer than with handling of digital certificates. Federating trust also depends on those services being reachable, not changing their Terms of Use, and being secure themselves. For a code distribution system that can have a real impact on businesses, this doesn't seem adequate.

But even digital package signatures would be separate of code-signing on the actual assemblies. In my opinion, it would be most useful just to surface that information. This leverages even more existing mechanisms (signtool.exe and Code-Access Security) and distills the problem to the core (trusting the assembly, not the associated NuGet package or profile). The UI challenge remains, but isn't insurmountable. E.g. add a "Signatures" column in ListAvailable, with value either "OK" or 2 numbers where lower is better: "[verify-failed]!, [unsigned]" (yes there's an exclamation point in there). Cost for cert also remains but is not extraordinary given the benefits (Tucows resells code-signing certificates from Comodo for $75/year).

Last point: laziness/cumbersomeness shouldn't play too big a role, as these can be addressed at fixed-cost with tooling, given demand.

As you said, trust is graded, not binary. It's also generally apparent that the more trustworthy the mechanism, the higher the costs/friction. Given this, it's not clear which mechanism, or set thereof, gives the best bang for the buck. Anyway, interesting article; thanks for writing it.
haacked • February 20th, 2013
Reharik: One of the guiding principles in NuGet's design was to try and be as close to what developers were already doing manually. The vast majority of packages simply put DLLs in a known location (packages folder) and add an assembly reference.

We considered naming it the "lib" folder, but decided it would cause too much conflict with folks already using that convention. But I think if we had, it'd highlight just how little magic a package has.

Now with config transforms and PowerShell scripts, packages can do a lot more than just drop the assemblies in a location, but those are actually more rare than you think.

Try reading the NuGet Docs site and hopefully it'll make you more comfortable with what NuGet does.

For example, another guiding principle is we only affect your solution. We never change things on your machine like registry settings etc. So after a package install, a git diff command should show you everything that changed.
haacked • February 20th, 2013
Thanks for chiming in! I wouldn't say I'm entrenched against them, I just think the reality is they hold more promise than they deliver.

For example, you mention that they're relatively cheap at $50-$100. But the cost is not just monetary. It's in the hassle to get one.

And as small as that cost+hassle is to you, it's clearly a barrier. Otherwise everybody would be signing their projects! So it's not that I don't think it's a great idea for everyone to do this. I do! I just don't think they will no matter how much you try to convince them. I think the VS Extension Gallery is evidence of this. They support signing and surface it in the UI, but apart from the ones shipped by MS, very few are signed.

Another way to look at it is I'm not being prescriptive against signing, I'm being descriptive of developers existing attitudes towards it.

A lot of the libraries in NuGet are small little libraries by one person working alone on a pet OSS project. Chances are they threw it up quickly and don't care to get the cert.

If we support signing, I would definitely want to surface that information in the UI. That's a no-brainer and a good idea.

I think the main point is, even if we did everything you suggested, I guarantee so few projects would do it that we'd have to still provide another mechanism to help people establish trust that's essentially "free" to developers.

Ultimately, I want to do it all! But I think we'll get more bang for the buck by the simple OAuth approaches to establishing identity first.

Again, thanks for the comment. It does make me think harder about the value of certs.
DWAK • February 20th, 2013
I bet if you just ignore the problem it won't be a big deal. Viruses that target Visual Studio users? Isn't it easier to just target Windows users? You have a much larger target with well-known attack vectors. And it's too easy to have malicious extensions or nuget packages removed from their respective galleries.

I appreciate the nod toward safety. I appreciate that you are concerned about the NuGet community. I'm just not seeing the benefit. Wouldn't a simple voting system accomplish much the same purpose? Or you know, put it on the developer to safeguard their machines. We spend at least $50/yr per developer on security-related software (Antivirus, anti-malware, sandboxes, etc). How about letting those guys do their job of keeping us safe and you you guys focus on making the best darn nuget you can.

In conclusion, I guess the point I'm trying to express is that I don't see it as NuGet's responsibility to keep me safe. It's my responsibility. I don't ask that Terminal.app keep me from shooting myself in the foot. Or my chat apps. Or my development environments. In fact, I dislike it when I'm told I can't do something that someone else considers high-risk (like emailing myself an exe in a zip file).
haacked • February 20th, 2013
I think NuGet is slightly different from Terminal or chat apps in its ability to pull down more software. I think of it as more like a browser.

The idea I'm trying to get at is to not prevent you from doing anything. Nothing in here restricts you.

Rather I'm trying to make sure NuGet has reasonable support for giving you the tools to protect yourself.

Much like when someone emails you a link to https://203.###.###/totally-safe-file.exe and you click on it and the browser lets you know "Hey, that might destroy your house." but it still lets you continue if you really want to. :)
Graham Hay • February 21st, 2013
I quite like the idea of packages having "permissions", something like the android app store. So you know, before installing, whether a package is going to fiddle with your config files, or run a ps script.

I realise that doesn't really help with your point :)
wwahammy • February 21st, 2013
True but I can verify that the package hasn't changed since creation by a particular individual or organization. Additionally, I know that an update to a package actually came from the same individual that created the original. It's not a panacea but it creates some trust. In some cases, verifying that my update came from a vendor like Microsoft instead of someone saying they're Microsoft is pretty important.

Again, I think the biggest problem is that the tools are just awful for signing and verifying signatures.
wwahammy • February 21st, 2013
The certs from a CA like Verisign are probably the highest level of trust because the identity is verified. On the lowest end you have a totally unsigned package. What about a middle choice like Android .apk's where people sign with user created keys or certs from an untrusted CA? That way you can verify that updates come from the same person that created the original package.

I think by supporting all choices and providing a view into that in the NuGet UI (have some sort of verification indicator or rating) you can improve trust using high quality, cryptographically secure mechanisms.
Mike McG • February 21st, 2013
Thanks for the reply. I see, re. prescriptive/descriptive. Yup, I totally agree that Joe Programmer rarely signs the binaries of his side project. I think it's fair to say, though, that this is at least in part because he knows few out there would notice; there's no value in it for him. NuGet can be the "responsible adult" by noticing these signing efforts and "rewarding" them with a reassuring "OK" or "Package Verified" blue checkmark annotation next to their work (while not penalizing unsigned packages). By virtue of this alone, (some) authors will feel incentivized to earn that reward as a point of pride or craft.

It does remain that getting and safely storing these certificates can be a hassle. Perhaps all we really need are `Request-Certificate [email]` and `Get-Certificate [email] [confimation-code]` commands ;-D
Ben Phegan • February 21st, 2013
One thing that wasn't covered in this discussion, but may have been thought of, is transitive trust and the due diligence package authors use when adding package dependencies. You may trust me, but I may be lazy....so I add some random package as a dependency to a package that I publish, and this will be pulled transitively into your solution. At install time you almost have to do a walk of the transitive dependency tree for the package you intend to use and validate not only the direct trust/authenticity, but make a call on the tree in its entirety.

This has possible impacts to install GUIs, as I would notionally want to see this at install time so I can make a decision at that point as to whether I trust all packages and authors in the tree. Some of this is mitigated by a "web of trust" and the shallow nature of most package dependency trees currently at nuget.org, but probably worth noting.
bsimser • February 22nd, 2013
The verification problem is one that's bugged me for a few months now but it's more about "what is the official package" not trusting the package. I thought about "verified nuget" or something similar to verified twitter accounts. What I would like to see is some central source (nuget.org sounds right) where a user registers his package and is verified to be the "official" package for that thing. For example when I type in SignalR I get all kinds of packages. Some are Microsoft, some are not. How do I know what the official package I should get it? How do I know which Autofac package is the right one? That's more what I would like to see. If I see the one "official" twitter bootstrap package out of the dozen or so ones out there I know it's known, supported, etc. (hopefully).
Kirk Wood • April 4th, 2013
What I want to know isn't that you compiled the NuGet package. I would rather know that GitHub compiled the package. Here is the thing: to the extent I trust GitHub, I can then trust that I have the same source available.

Do I trust you, sure. But I would have more trust knowing that your employer said that the package matched what I can get there. This is the real power of open source. I can look over the code and see what it does. If trouble arises I can compile and debug into the code. And I have a certain amount of trust that others have looked through said code.

Your suggestions might help. But I would like to know that the source matches the dll. And you could make some change before compiling. Sure, it is your code. But is it the code you placed out for me to see?
Sean Woodward • May 3rd, 2013
Phil's post touches on a very deep issue. One I believe has no real solution in site (on this I hope to be proved wrong). NuGet and other package managers create an interesting point of vulnerability. Developers learn early not to repeat themselves or to solve problems already solved. Naturally, we gravitate to easy to use solutions that address our needs and allow us to reach our end goals efficiently. Using a tool like NuGet, or any other package manager, allows us to tap a vast resource of solved problems, but can also expose us to subtle bugs, illusive issues, or worse vulnerabilities or exploits both explicit and intrinsic. Unfortunately NuGet installs compiled binaries, I assume many, but at least some, come without a true list of dependencies. A convenience yes, but also a potential nightmare for those that are not most vigilent. The tradeoff for that convenience is not always immediately evident.

The Dependencies section of a NuGet package can be very misleading. While a package may report, "This package has no dependencies", it's payload can be quite a different story. Packages can include any number of dependencies without our knowledge. ILMerge allows multiple libraries to be bundled into a single library. Many of our favorite packages, even those distributed by trusted Microsoft authors, use this method to wrap dependencies in a single library. The issue now becomes not just how much do we trust the author of the package, but how much do we trust the author's trust in the libraries included and embedded without our knowledge, and so on. What our packages need is a something similar to a "Nutrition Facts" label. This information should include a list of all libraries required and included with the package. NuGet addresses the first but does not deliver the latter. Additionally, I like to see a set of criteria identifying the checks the library has passed should be included with the package's "Nutritional Facts". These facts would provide top-level indicators and categories measuring the reliability or trustworthiness of a given package.

Phil says, "At least with NuGet, when you install a package it doesn’t require elevation. If you install an MSI, you’d typically have to elevate privileges." If the privileges are not required or present during development, often these privileges will be required during installation. Therefore, elevation is many times merely just deferred.

I agree package signing is not a solution in and of itself, but a better "Ingredients List" and "Nutritional Facts" of a given package would be a better approach.
David Burg [daviburg@MSFT] • October 9th, 2013
As my team started publishing nuGet packages I looked on how to sign them, as we have a corporate policy that anything you install on a corporate machine should be signed (by a trusted source, not a random self-signed certificate). I landed here and understand package signing is not supported at this time. To the point of "who would use this anyway?", well my team would. We are already signing all assemblies, msi, executables that we release.
Oisín G. • July 29th, 2014
This is an old comment, but just in case someone else arrives here with a similar sentiment: https://www.nuget.org/packa...
Martin Brown • December 3rd, 2014
It always amazes me that any of this code reuse works in practice. The complexities of including someone else's code don't just come from malicious code, they also come from intellectual property issues and lets face it very few developers actually pay any attention to these issues, they are too busy creating the next cool thing.
If I include open source code in a closed source application I may be breaking a contract. Likewise a package developer may have included copyrighted or worse patented code in an open source package without checking.
Still the whole reason why this isn't an issue is more to do with no one really enforcing any of these licences anyway. Maybe the accountability that signing would give may actually be a good thing. Because what we are really after is the inability of a package developer ducking out of their promises.
Greg Sohl • December 29th, 2015
Any update on where we are with the NuGet trust "issue"? I have seen the post on package signing http://blog.nuget.org/20150.... But wondered if you had any new take on it.
haacked • January 6th, 2016
I haven't heard anything from the team on this other than they were exploring package signing.
slothbag • February 26th, 2016
I had been using random authors packages due to popular authors not keeping their packages up-to-date, and then realized the huge security risk that comes with that.

I am in the process of trying out the gx package manager (https://github.com/whyrusle... as an alternative to nuget. Its not language specific, it supports any language.

It uses IPFS under the hood to reference the package as a hash of its content, this way the contents can be verified once either by a deterministic compilation by many or by a trusted author and if the hashes match we are good to go. You cant change the content without the hash changing.

The other benefit is no central server like nuget.org to get hacked, basically each author sets up their own mini repo, if my project uses bootstrap and pgsql I would add both of those authors as mini repos and then receive future updates as they happen from the authors.

For package updates I would check github changelog to make sure a new update has related commits, otherwise the mini repo owner could have been hacked and I shouldn't download the latest version until confirmation.

It seems like this might be the way to go.
Guest • December 25th, 2016
I prefer the days when the standard approach was to pull down raw source code, review it myself, and then compile it myself. Then, I knew it was safe, and I knew what the dependencies were, and I could manage it myself. I may be old-school, but I am highly concerned about security these days and about tracking dependencies and version compatibility.