Re: bash exorcism experiment ('bug' 762923 & 763012)
On Thu, 2014-10-02 at 20:43 -0700, Russ Allbery wrote: > A lot of people miss this about Policy 10.4. People seem to think that > Policy 10.4 is about requirements for shell scripts. But it's just as > much a standard for /bin/sh. You wrote it, so I guess you get to say what it means. But if you hadn't said so just now, I'd be using the "People"'s interpretation rather than yours. 10.4 is after all titled "Scripts", not "a sh language definition" or some such. Where it does define the shell language, it does so in in this context: "Scripts may assume that /bin/sh implements ...". So to me it is addressing itself to script writers, not sh language designers, and to extent it describe the the shell language standard is does to purely to inform the script writers what environment they can expect when they use "#!/bin/sh". > This was important when we were debating switching from bash to something > else, and needed to be clear about what behavior the rest of the > archive could expect /bin/sh to always satisfy. I looks to me like you are re-writing history. Right back in the 2.1.3.2 policy was pretty much what it was now. "#!/bin/sh" scripts had to be POSIX - albeit with less extensions than we allow today. If policy was so good at informing the debate about what "#!/bin/sh" scripts did, I'd be surprised there was much in the way of a debate. You could have switched to any shell that implemented the POSIX subset with very little pain. So this statement of yours: "we ... needed to be clear about what behavior the rest of the archive could expect /bin/sh to always satisfy" is puzzling, because there was pain. Everyone knew what /bin/sh did - it was defined in the bash man page. Since bashism's worked just fine, and evidently regardless of what policy said no one cared whether you used bash'ism or not so they were used with gay abandon. If as you suggest Debian relied on policy for a clear description of how /bin/sh scripts behaved, it was in for a rude shock. It didn't of course. Debian got the clear description it needed by writing automated checkers like checkbashism, followed threats to change /bin/sh away from /bin/bash, mass bug filings and finally in 2011 doing it. I am not criticising any part of this process. Standardising its shell language was huge undertaking for Debian, and pull it off almost without a hitch. It's the sort of thing that makes me proud of the project. What I am questioning is your assertion that policy that wasn't verified let alone enforced was somehow key to it. > I think people often don't realize what Policy is actually about, or what > it can (and can't!) accomplish. Policy is more a way for us to coordinate > our work and agree on what we're actually talking about than an enforced > set of rules that are followed. Again, you've lost me. Yes, policy that is followed and policed is very useful. It is very nice have man pages for almost everything. For me its essential I can rely on Debian's copyright policing. But to use this example again, you are saying the agreeing that "#!/bin/sh" scripts shall be POSIX shell scripts, and then largely ignoring it for 10 years because it is unverifiable was helpful to the project? I don't see how it saved anyone any time. > So yes, there's a lot of Policy that is ignored in practice. You can take > various attitudes towards that. You can view that as meaning Policy is > (at least partly) worthless because we're not enforcing it. Or you can > decide that Policy is more aspirational than descriptive. Or you can > focus on the change Policy has helped make happen. I think all those > viewpoints are accurate to a degree. OK, but realise you are making life hard for some of us here. Perhaps you, as one of the policy author's know what bits are hard and fast rules and which bits are purely aspirational. I don't. I guess if we less knowledgeable folk finding ourselves disagreeing with some policy, we can try assuming it's aspirational and ignore it. Yes, it made me cringe to write that. But you are telling me it is the way Debian works now. And I get the impression you think this is a good thing. > As bad as you think the compliance with Policy 10.4 is right now, I > guarantee that the prospects of being able to use something else as > /bin/sh would be way worse if we did what you suggest. Ah! And here we is our fundamental point of difference. It is beyond me how you could think that could be so. So much so that I'm doubting my comprehension abilities. I do have this right - the goal is to ensure "#!/bin/sh" scripts use a standardised subset of the shell languages out there? That way should a user change a different /bin/sh, he can be reasonably sure it will work if implements this well defined subset. (And yes, I acknowledge the subset is well defined in the current policy - well done.) To achieve that end you are proposing all we do is ask developers nicely to use that subset. The alternative I
Re: bash exorcism experiment ('bug' 762923 & 763012)
Russell Stuart writes: > On Thu, 2014-10-02 at 20:43 -0700, Russ Allbery wrote: >> A lot of people miss this about Policy 10.4. People seem to think that >> Policy 10.4 is about requirements for shell scripts. But it's just as >> much a standard for /bin/sh. > You wrote it, so I guess you get to say what it means. But if you > hadn't said so just now, I'd be using the "People"'s interpretation > rather than yours. 10.4 is after all titled "Scripts", not "a sh > language definition" or some such. Where it does define the shell > language, it does so in in this context: "Scripts may assume that > /bin/sh implements ...". So to me it is addressing itself to script > writers, not sh language designers, and to extent it describe the the > shell language standard is does to purely to inform the script writers > what environment they can expect when they use "#!/bin/sh". We had a lot of discussions about this on debian-policy at the time. I suppose it's possible that I'm misremembering, but I'm pretty sure I'm not. That's specifically what the phrasing "scripts may assume" is trying to drive at: this is the functionality that you can assume that /bin/sh has, which in turn creates a requirement for /bin/sh. I'm sure the wording could be clearer. Wording always can be. :) >> This was important when we were debating switching from bash to >> something else, and needed to be clear about what behavior the rest of >> the archive could expect /bin/sh to always satisfy. > I looks to me like you are re-writing history. I'm not sure how you meant this, but to note, this sentence made me very sad, since it felt like you believe I'm being intentionally dishonest with you. I'm really not, although I'm not sure how to convince you of that. Maybe you actually meant to say "misremembering" (something that could be accidental) rather than "re-writing" (which is usually taken to be intentional and deliberate)? Anyway, I think the key misunderstanding is here: > So this statement of yours: "we ... needed to be clear about what > behavior the rest of the archive could expect /bin/sh to always satisfy" > is puzzling, because there was pain. Everyone knew what /bin/sh did - > it was defined in the bash man page. Since bashism's worked just fine, > and evidently regardless of what policy said no one cared whether you > used bash'ism or not so they were used with gay abandon. If as you > suggest Debian relied on policy for a clear description of how /bin/sh > scripts behaved, it was in for a rude shock. That's not what I was getting at at all. Rather, that portion of the policy received a lot of work and attention, some rewordings, and a lot of expansion during the time period when the project was working on replacing /bin/sh with dash. The specific list of exceptions was expanded based on that work; they were the things that we chose to accept on top of a POSIX shell because getting rid of them would have otherwise have been too much effort. That section of Policy was written hand-in-hand with writing checkbashisms and with pushing the archive towards working with dash. > It didn't of course. Debian got the clear description it needed by > writing automated checkers like checkbashism, followed threats to change > /bin/sh away from /bin/bash, mass bug filings and finally in 2011 doing > it. Policy 10.4 is a key part of the specification for checkbashisms and the justification for the mass bug filings. These were not independent efforts. > I am not criticising any part of this process. Standardising its shell > language was huge undertaking for Debian, and pull it off almost without > a hitch. It's the sort of thing that makes me proud of the project. > What I am questioning is your assertion that policy that wasn't verified > let alone enforced was somehow key to it. We did not ever go all the way to verifying that everything in the archive would work with a shell that exactly conforms to the minimum Policy requirements and no more. The farthest we ever got was to get dash to work. I thought that's what you were getting at when talking about testing, and I was agreeing with you that we didn't test against non-dash shells. What I don't agree with is the idea that Policy should therefore just say that scripts have to support dash, rather than saying what it says now. (I thought you were arguing for that; maybe I'm wrong.) > But to use this example again, you are saying the agreeing that > "#!/bin/sh" scripts shall be POSIX shell scripts, and then largely > ignoring it for 10 years because it is unverifiable was helpful to the > project? I don't see how it saved anyone any time. I don't think it *was* particularly helpful prior to when we did the work of switching to dash. But during that effort, Policy was quite helpful in communicating what script writers could rely upon, and in driving specifications of other tools, like checkbashisms. And providing sanction to mass bug filings. Now that da
Bug#763916: ITP: node-browserify-lite -- bundle client-side JavaScript using Node.js-style module syntax
Package: wnpp Severity: wishlist Owner: Andrew Kelley X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-browserify-lite Version : 0.0.1 Upstream Author : Andrew Kelley * URL : https://github.com/andrewrk/browserify-lite * License : Expat Programming Lang: JavaScript Description : bundle client-side JavaScript using Node.js-style module syntax browserify-lite scans a JavaScript file for require() statements and then resolves the dependency, recursively scanning dependencies for require() statements, resulting in a JavaScript bundle that can be sent to the browser. . Node.js is an event-based server-side JavaScript engine. . This module is needed as a build-dependency for Groove Basin. See http://bugs.debian.org/752829 I plan to maintain it as part of the pkg-javascript team.
Bug#763930: ITP: mysecureshell -- SFTP Server with ACL
Package: wnpp Severity: wishlist Owner: Pierre Mavro * Package name: mysecureshell Version : 2.0 Upstream Author : Pierre Mavro * URL : http://mysecureshell.readthedocs.org * License : GPL Programming Lang: C, Perl, Shell Description : SFTP Server with ACL MySecureShell is a solution which has been made to bring more features to sftp/scp protocol given by OpenSSH. By default, OpenSSH brings a lot of liberty to connected users which imply to thrust in your users. The goal of MySecureShell is to offer the power and security of OpenSSH, with enhanced features (like ACL) to restrict connected users. MySecureShell was created because of the lack of file transfer features in OpenSSH. OpenSSH was not designed as a file transfer solution, that's why MySecureShell is born. MySecureShell is not a patch for OpenSSH, it's a shell for users. It has the advantage to: * Avoid including security holes in OpenSSH * No dependence on against an OpenSSH version This package is largely used in banking systems. It allows OpenSSH to have a fine grained filtering restriction on user connections. I'm looking for a sponsor to add this version and next versions in Debian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141003220854.11593.94584.reportbug@8d573f72
