Re: revision control downloads
On Mar 22, 2022, at 13:08, Daniel J. Luke wrote: > On Mar 21, 2022, at 9:20 PM, Ryan Schmidt wrote: >> Ports that fetch their sources from a revision control system do not enjoy >> the protection of checksums. Although ports that fetch source from a >> revision control system specify which tag or commit hash to fetch, it is >> conceivable that a developer with sufficient access to that repository could >> delete an old tag and replace it with a new tag of the same name that >> contains different software. This is one of the reasons why we recommend >> ports fetch using distfiles, and the vast majority do. We might consider >> recommending that ports that fetch directly from a git repository >> (fetch.type git) never use a tag, and always use the commit hash >> corresponding to that tag, since replacing the contents of the repository >> while keeping the same sha1 hash is, as far as I know, still impossible in >> the general case. (Yes, it is possible to engineer a sha1 collision, but >> only if you can carefully control both the old and new files. Generating a >> sha1 collision against some existing old file is a very different matter.) > > I haven't reviewed the current literature but one thing is certain - attacks > only get better. We should strongly discourage any use of revision control as > the source. As I said we do already and have for a long time strongly discouraged using revision control systems for downloads. > We could shorten the window where a person could get sources that don't match > what the maintainer expected with a little infrastructure magic. Roughly in > order of presumed level of effort: > > - provide a place for maintainers to manually upload distfiles that they can > generate from a source checkout > - provide some port command for maintainers to upload distfiles (as a > convenience for the above upload process) > - have a process that automatically generates distfiles from the checked out > source and puts it on our mirrors (builder could probably do this since it's > already going to check out the source), then have base look for the distfile > on our mirrors first (even if the portfile specifies to check out from a > revision control system) Rainer did some work on automating the creation of distfiles from revision control systems but it has not been touched in some years. Since Rainer hasn't been very active here lately maybe someone else would like to pick it up and finish the work. https://github.com/macports/macports-base/tree/vcs-fetch
Re: Codesigning everything and combatting malicious code
On Mar 21, 2022, at 23:02, Joshua Root wrote: > We could ad-hoc codesign everything, which would not improve security at all, > but would get GateKeeper to ease up a bit on restrictions on incoming network > connections and the like. > Assurance that binaries have not changed after being installed would be nice > I suppose. Ok, those could be useful qualities. A binary could change because of malicious actions or just because the disk it's stored on is failing. Preventing the binary from being used in either of those cases is probably good. If we did ad-hoc codesiging in MacPorts then we would not need to use any Developer ID and we would have the same safeguards for Intel and PowerPC systems that we already have automatically on Apple Silicon systems. Would that be of any benefit? "man codesign" says "Significant restrictions apply to the use of ad-hoc signed code; consult documentation before using this." I don't know which documentation it means. I found this page discussing the restrictions: https://apple.stackexchange.com/questions/288291/what-are-the-restrictions-of-ad-hoc-code-signing Most of the answer provided there is incomprehensible to me except for the conclusion that an ad-hoc signed binary is "basically [...] the same as a non-signed binary". Are we sure that ad-hoc codesigning is enough to pacify GateKeeper? Since all binaries must be codesigned on Apple Silicon, does that mean that GateKeeper never has anything to complain about on Apple Silicon systems? The code signature appears to be stored within the file being codesigned. (I ad-hoc codesigned an unsigned binary produced by MacPorts and its size increased by 25K.) What happens if file is completely replaced? I assume the previous file's code signature does nothing to prevent that. We have at times had the situation where a user runs a third-party installer that installs older files on top of the files MacPorts installed, causing various problems. But I'm guessing codesigning wouldn't do anything to prevent that situation, in which case codesigning doesn't really prevent modification of the file in the way that one might expect. > Codesigning is a in the end just a mechanism, and there are policy questions > that need to be thought through before it can be useful. Yup, and thanks for raising some of those questions in your response!
Re: Codesigning everything and combatting malicious code
Apologies if what I'm about to say seems tangential... hopefully it provides historical context that is useful to the discussion at hand. = Remember that code signing was first implemented for apps that were published on the iOS App Store. This was very quickly (maybe even simultaneously?) adopted for the Mac App Store. Since the code signing was generally seen as "a good thing"™ in terms of security, Apple has since rolled it out nearly everywhere. Some people, including me, have seen this as just one more indication of the "iOS-ification" of the Mac operating system, a process which began when they renamed Mac OS X to macOS. Another example of the "iOS-ification" of macOS is where, starting in Catalina, and then in Big Sur, Apple moved the System volume to a partition that is mounted read-only, and then also sealed that volume into a Signed System Volume (SSV). (See? there's that word again... "Signed".) This structure of a read-only and signed volume that contains the entire operating system is the way that iOS has been structured for a very long time (maybe even since the beginning). Getting around this structure, and turning the volume where iOS resides into one that is read-write, is one part of what is generally referred to as "jailbreaking" iOS. Apple's app stores are highly centralized, being 100% hosted, administered, and controlled by a single entity. Thus, they have a need for code signing, so that they can use the code-signing keys as a mechanism to control whether or not a third-party developer's app is allowed to be visible to the public through their (first party) app stores. On the other hand, MacPorts is much more similarly structured *—* in terms of infrastructure, governance, and philosophy *—* to a package manager on Linux, and is highly decentralized. This sentiment appears to be echoed in Wikipedia's article on code signing (https://en.wikipedia.org/wiki/Code_signing), in the last paragraph of the section entitled "Providing security". In particular, I would like to point out the citation at the end of that paragraph, which links to a discussion of apt-secure on the Debian wiki ( https://wiki.debian.org/SecureApt). If you read through the Debian wiki page, you will see that, circa 2003-2005, when Debian moved away from simply using MD5 checksums, they decided to go the route of using public key cryptography in the form of GPG keys, instead of going down the road of code signing the way that Apple has implemented it. = On Tue, Mar 22, 2022 at 12:02 AM Joshua Root wrote: > On 2022-3-22 12:20 , Ryan Schmidt wrote: > >> Could MacPorts codesign everything installed by ports? If so, should we? >> What benefits would that bring? How would we do it? > > > We could ad-hoc codesign everything, which would not improve security at all, > but would get GateKeeper to ease up a bit on restrictions on incoming > network connections and the like. If ad-hoc code-signing everything would not involve the need for anyone, either on the MacPorts side or the user side, to have a Developer ID, then it seems like this would generally be a good idea. Reducing the number of interactions with GateKeeper would help reduce user confusion. (Does anyone remember the frequency of the UAC prompts in Windows Vista?) Doing actual useful codesigning would require a few things: > 1. A Developer ID for the project. I'm happy to sign the installers with my > personal Developer ID because I build them myself and I am familiar with > the code contained in them. I would not sign arbitrary third party code. > 2. A Developer ID for every user who needs to install any ports that are not > available as binaries. We obviously can't distribute our secret key to > the public, so anything built locally needs to be signed locally, with a > locally configured identity. > This seems like it would be adding a huge burden onto people who simply want to use MacPorts. > 3. A willingness to endorse every binary we ship by putting our signature > on it. > Does MacPorts, as a group of developers, really want to be in the business of endorsing every binary that's available in our catalog of nearly 30,000 packages? The various Linux package management systems certainly don't make any such claims or guarantees, and in fact explicitly state the opposite. And even though Apple also has text stating that they don't "endorse" any apps in their app stores, the fact of the matter is that they do still take it upon themselves to police the apps (and the developers) on their app stores. This also relates back to point #1, where the MacPorts Developer ID would be getting used to arbitrarily sign third-party code. 4. A plan for what to do if we inadvertently ship malware and our Developer > ID certificate is revoked. AIUI, that would make it impossible to run > anything signed with the existing certificate if GateKeeper is enabled. > Everything would presumably have to be re-signed and reinstalled. > I believe Josh is correct. A
revision control downloads (was Re: Codesigning everything and combatting malicious code)
On Mar 21, 2022, at 9:20 PM, Ryan Schmidt wrote: > Ports that fetch their sources from a revision control system do not enjoy > the protection of checksums. Although ports that fetch source from a revision > control system specify which tag or commit hash to fetch, it is conceivable > that a developer with sufficient access to that repository could delete an > old tag and replace it with a new tag of the same name that contains > different software. This is one of the reasons why we recommend ports fetch > using distfiles, and the vast majority do. We might consider recommending > that ports that fetch directly from a git repository (fetch.type git) never > use a tag, and always use the commit hash corresponding to that tag, since > replacing the contents of the repository while keeping the same sha1 hash is, > as far as I know, still impossible in the general case. (Yes, it is possible > to engineer a sha1 collision, but only if you can carefully control both the > old and new files. Generating a sha1 collision against some existing old file > is a very different matter.) I haven't reviewed the current literature but one thing is certain - attacks only get better. We should strongly discourage any use of revision control as the source. We could shorten the window where a person could get sources that don't match what the maintainer expected with a little infrastructure magic. Roughly in order of presumed level of effort: - provide a place for maintainers to manually upload distfiles that they can generate from a source checkout - provide some port command for maintainers to upload distfiles (as a convenience for the above upload process) - have a process that automatically generates distfiles from the checked out source and puts it on our mirrors (builder could probably do this since it's already going to check out the source), then have base look for the distfile on our mirrors first (even if the portfile specifies to check out from a revision control system) -- Daniel J. Luke
