"Joseph R. Justice" <jayarejay@gmail.com> writes: >> Here are some factors to consider: >> >> 1) It's not clear to several TC members that the FTP team has decided >> on this question. It seems fairly clear how they would decide if they >> did decide, but from a process standpoint, it's important to have a >> formal dialogue with them before they are overruled. > > I'll be honest, I assumed from what I've read that a decision had already > been made by the FTP team against Mr. Praveen. I figured that it must have > been, or else why would he be raising this bug with the TC now? Well, quite. Joseph, thanks for you efforts here, I think some light has been shed ( although as a dyslexic, shorter/fewer mails would be helpful ;-) That being the case I'm just going to reply to one mail and cover some of the points that you raised across several). I'm just writing as an individual here BTW, but I'll obviously carry these views into any discussion that the TC might have about this. The repeatedly presented request is for a ruling on the question of 'browserified javascript' in general. There are two serious problems with that straight away. Firstly, none of the people being asked to make to that general decision are used to making general statements on such matters, and many/most of them think that doing so is a bad idea. Secondly, 'browserified' is poorly defined, and repeated attempts to clarify its meaning seem to have been ignored. Pretty much any response that any of us might be hoped to make to such requests are things we're unwilling to say because we reject both the assumption that a general statement is a good idea, and don't want to make statements that are then open to wild reinterpretation because of the fluffy terminology. So we end up asking what look like picky, annoying questions about small details in order to try and get something concrete to talk about. Meanwhile Praveen is only interested in fixing the whole problem at once, and pushes harder to get a general response. This is not working. Speaking purely for myself, no matter how trivial the transformation being done to the source, I see no compelling reason for an exception. My reason being more to do with the practical consequences of allowing such an exception, than the subtle issue of what might constitute source. Assuming for the sake of argument that the request for a special exception were granted, then: Let's imagine that there's one-line npm library that has an (as yet undiscovered) flaw that allows some sort of serious remote attack. Also, that library is popular enough to be included in numerous "browserified" libraries, which because of the exception get packaged, and then included in a release, and are depended upon by the likes of gitlab and other such packages. Wait a couple of years, and then discover the bug. In the mean time, some of the browserified libraries have become unpopular, and no longer have upstreams and because of developments in grunt can now only be built with an obsolete version of grunt. Some have refactored and can now only be built with the latest version of grunt. Some have moved on and no longer use the faulty code at all, so have no interest in helping fix old versions. The security team are going to have to track down every instance of that code and fix it. If the bug is something to do with an interaction between the code and the tools used to "browserifiy" the code, that may be non-trivial. We have no real control over which versions of those tools were used, and various upstreams are likely to say "just upgrade" or thay may present us with vastly different versions of the browserified code, especially if they've switched to different tools in the mean time. None of this seems compatible with our normal security processes. In a perfect world the person doing the security fix would go to the buggy code in its own library, and then upload a new version, provoking all the other packages to be rebuilt. Job done. Of course, for that to happen we'd have to start accepting tiny javascript packages, which is currently not happening (which also seems to be a blocker to grunt being packaged BTW). In conclusion, Praveen's asking a question that I see no real prospect of getting an answer in its current form. In fact, I'm yet to imagine a way of framing this question that would result in any of the packages being acceptable in 'main' and I don't see any problem with them being moved to a combination of contrib and non-free -- I think that is actually the correct outcome, because it gives the correct impression about the level of security support they should expect for those packages. It also doesn't encourage people to use packages that might well be removed in a subsequent release. How good would it be, for instance, if in the lifetime of Squeeze, Alioth were migrated to gitlab, only for it to be removed from Squeeze+1 when grunt proves to be unpackageable? Temporoary exceptions to enter main are not a good idea. Cheers, Phil. P.S. BTW Drawing comparisons with perl Configure may be intellectually invigorating but does nothing to address the above mess. With browserification, the dubious output ends up running on network facing machines (both Debian servers, and their heterogeneous web clients) so the attack surface is vast. The code development is fast-moving, and the people developing it are often unsympathetic to the idea that one might not want to upgrade to their latest version. Perl's Configure on the other hand is slow moving with changes quite often being things like adding support for obscure hardware that we don't even dream about supporting e.g.: http://perl5.git.perl.org/perl.git/commitdiff/86ea01eb2de6e15e79ff54031d7fabfb5f628d4e#patch1 Also, this code is only run during the build process. You'll also note that people are routinely developing upstream by modifying that code directly. I've found no evidence of that at all so far when looking at browserified code. Personally I'd prefer it if we could rebuild Configure in Debian, but I'm not going to make that so myself. Campaigning for perl to be removed from Debian doesn't strike me as a worthwhile use of one's time. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature