3 ms·

"So, you're telling me that the preferred form for making modifications to the source code of a router does not include the scripts which install onto the route

• AnthonyMouse 11y ago
  > Scripts used to control compilation and installation != signing keys. You're referring to "scripts used to control compilation", but how are signing keys not part of the source code? GPLv2 uses a specific definition of source code, "the preferred form of the work for making modifications to it." Don't you have to be arguing that a form not allowing modifications to be used or tested is the "preferred form of the work for making modifications"?
  • DannyBee 11y ago
    "" Don't you have to be arguing that a form not allowing modifications to be used or tested is the "preferred form of the work for making modifications"?" You are trying to take parts out and remove context from them. I don't have to argue at all about the preferred form, because it very explicitly says what that is: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." The first two sentences go together. It defines, explicitly, what the preferred form of complete source code for an executable work includes. So that isn't going to include signing keys unless you want to argue that one of the explicitly enumerated parts includes signing keys. For years, people have argued back and forth about whether the scripts include data files. The general consensus is "no", because otherwise, it has no differentiable meaning from the other parts.
  • MaulingMonkey 11y ago
    Do you check your private GitHub keys into VCS? Your wide definition of "scripts used to control compliation" would seem to include them! My preferred form of making modifications to my software includes uploading them to my GitHub account for code reviews among other things. I use my GitHub private keys way more often than final code signing keys - be those keys used for as "nefarious" a use as tivoization lock-in, or as benign a use as proving authorship so Windows can tell my executables apart from some asshole's malware better. During standard development I'm either using temporary, machine-local certificates, or using unsigned code. If that means I need a devkit, or an emulator, or a dongle, or whatever else might be required to iterate that doesn't require the final "publishing" steps, in a well designed system it shouldn't require final publishing certs. Because for security's sake, you'd consider going to such lengths as keeping those code signing certs on a tightly controlled, air gapped machine, to reduce the chance of getting pwned and dealing with cert invalidation. Or worse. Which makes it a very far cry from being part of your compilation phase in any capacity, nevermind a script used to control it.
    • AnthonyMouse 11y ago
      You haven't read what I wrote. But the "preferred form of the work for making modifications" presumably involves each person using their own github keys (and/or repositories) etc. Anybody can create an account and use github. That is not true in the tivoization case because in that case the only keys that can be used are the original ones.
      • MaulingMonkey 11y ago
        > You haven't read what I wrote. Are you sure? Based on what? I've managed to quote you without the use of copy and paste in that previous post - I'm not sure how I accomplished that if I didn't read what you wrote - so please be more specific. This also begs the question: Did you read what I wrote? > But the "preferred form of the work for making modifications" presumably involves each person using their own github keys (and/or repositories) etc. And the "preferred form of the work for making modifications" also presumably involves each person using their own signing keys (and/or hardware that may not require them) etc. > Anybody can create an account and use github. Anyone can buy their own hardware, and compile for it, and install on it. Just don't pick tivoized hardware. > That is not true in the tivoization case because in that case the only keys that can be used are the original ones. The source code is not tivoized - hardware is. So don't pick tivoized hardware.
  • tptacek 11y ago
    In actual fact, on many (perhaps most) platforms for which code must be signed, the developers on those platforms don't have to bother with code signing to develop and test their own code; it's stubbed out in the development environment. So even a reaching definition of "preferred form for modifications" doesn't hit signing keys, just like "preferred form" of a Rails app doesn't include your EC2 credentials.
    • mindslight 11y ago
      "modification" applies specifically to the code as is installed and shipped. Picture the scenario at the manufacturer where one developer is being tasked with creating a new feature using a consumer unit fresh off the line, for a business demo. What resources do they utilize in the course of doing this? This is the company's "preferred form" of the source tree for modifying an as-shipped device, and is what needs to be made public. The company could supply a firmware update to overwrite the bootloader and stub out signature checking, if that is what makes sense. Or a well-specified description to use JTAG to do the same. Or perhaps they don't actually care about security and 'make dist' creates an installable image. The thing is, all of these arguments ("preferred form for modification", the key being part of the installation script, code+signature being the executable work) seem like uphill battles when trying to show the manufacturer is violating them in an informal forum like HN. But the intent and spirit of the license is straightforward and even spelled out in the preamble! "Our General Public Licenses are designed to make sure ... you can change the software". Fulling these goals is the entire point of the contract and only consideration for receiving a license. So the manufacturer is actually the party that must work to show how what they're releasing actually fulfills the specific terms.
    • AnthonyMouse 11y ago
      > In actual fact, on many (perhaps most) platforms for which code must be signed, the developers on those platforms don't have to bother with code signing to develop and test their own code; it's stubbed out in the development environment. What is the relevance of that supposed to be? You can put any part of the development process on any number of different computers or distribute the work between different developers however you like. And the relevant "preferred form for modifications" is presumably the form the user uses to make modifications to the device delivered to the user in any event. > So even a reaching definition of "preferred form for modifications" doesn't hit signing keys, just like "preferred form" of a Rails app doesn't include your EC2 credentials. Why wouldn't it include your EC2 credentials (or other root access to the instance) if conveying an EC2 instance to the customer is how the customer receives the software from you? But now you're wading into the SaaS vs. software distribution ambiguity which has nothing to do with the case where you've bought a physical device with the software on it.
• thaumasiotes 11y ago
  I have to imagine that the scripts controlling installation must sign the executable. (Assumption: unsigned executables can't be installed.) They can only do that by incorporating the signing keys. They might incorporate the keys by including the keys literally within the script proper, or by reading a file that contains them, but why are those situations different? Suppose the installation script defined a lisp interpreter and then read a data file which, when interpreted by the lisp interpreter defined in the script, installs the executable. Why isn't that data file also part of "the scripts used to control installation of the executable"?
  • DannyBee 11y ago
    "I have to imagine that the scripts controlling installation must sign the executable. " This is a pretty big assumption, and in fact, is not actually true in a lot of cases :) Let's assume it is here. "Why isn't that data file also part of "the scripts used to control installation of the executable"?" Because the data file literally isn't a script used to control installation of the executable? It's a data file. At best, btw, you'll be able to argue that it would have to include the signing key, but not any password for it. So you are still pretty screwed :) Your argument also swallows the definition. Where does it end? Do i have to include the interpreter for the script, and provide source? Why not, since it's required for the script to function. (Note, this would not be covered by the next exception in a lot of cases) If i give you a bash script The installation script also almost certainly refers to the executable, but that's called out explicitly as something i have to give you source to. Why bother if it's included in the "scripts to control compilation/installation" part? (In general, courts are going to read definitions into things that make parts of enumerated lists differentiable from each other ) In general, i would say you can go down this path, but you won't get a court to come with you. Scripts means scripts. Data files means data files. If the key is literally part of the script, yes, you'd have to ship that. Not the password, mind you. If they wanted something else, they should have written something else. Which they did, in gplv3 ;)