Re: goals for hardening Debian: ideas and help wanted
Apologies for the top posting, I'm writing this from my phone. I get a 403 when trying to access via Orbot/Orweb on Android 4.1 phone. Amusing. Lesley On 24 Apr 2014 03:58, "Paul Wise" wrote: > Hi all, > > I have written a non-exhaustive list of goals for hardening the Debian > distribution, the Debian project and computer systems of the Debian > project, contributors and users. > > https://wiki.debian.org/Hardening/Goals > > If you have more ideas, please add them to the wiki page. > > If you have more information, please add it to the wiki page. > > If you would like to help, please choose an item and start work. > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise >
Re: goals for hardening Debian: ideas and help wanted
On 10:57 Thu 24 Apr 2014, Paul Wise wrote: > ..[snip].. > https://wiki.debian.org/Hardening/Goals Regarding the line (at that page): > Refuse to install packages that are known to have X number of unplugged > exploits (i.e. X number of open security bugs in the bug tracker) unless > e.g. --allow-vulnerable-packages is used. This makes it clear that you are > installing software that is vulnerable. I suggest it might be better if exploits were each given a quick/approximate "ranking" in terms of severity (and if the severity is unknown it could be assigned a default median ranking), so that the algorithm you mention wouldn't just add number of unplugged exploits, but add them by weight. For example: the recent heartbleed exploit would be worth more than a few smaller exploits in less critical software, and would be calculated as such... -- PGP fingerprint: BB0A 0787 C0EE BDD8 7F97 3D30 49F2 13A5 265D CCBD -- 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/20140424080627.GB31307@hernia
Bug#745704: ITP: ruby-omniauth-tumblr -- OmniAuth strategy for Tumblr
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil * Package name: ruby-omniauth-tumblr Version : 1.1 Upstream Author : Jamie Wilkinson * URL : https://rubygems.org/gems/omniauth-tumblr * License : Expat Programming Lang: Ruby Description : OmniAuth strategy for Tumblr -- 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/20140424080539.29538.43848.report...@ravel.debian.org
Re: goals for hardening Debian: ideas and help wanted
On Jo, 24 apr 14, 11:06:27, Rowan Thorpe wrote: > On 10:57 Thu 24 Apr 2014, Paul Wise wrote: > > ..[snip].. > > https://wiki.debian.org/Hardening/Goals > > Regarding the line (at that page): > > > Refuse to install packages that are known to have X number of unplugged > > exploits (i.e. X number of open security bugs in the bug tracker) unless > > e.g. --allow-vulnerable-packages is used. This makes it clear that you are > > installing software that is vulnerable. > > I suggest it might be better if exploits were each given a quick/approximate > "ranking" in terms of severity (and if the severity is unknown it could be > assigned a default median ranking), so that the algorithm you mention wouldn't > just add number of unplugged exploits, but add them by weight. For example: > the recent heartbleed exploit would be worth more than a few smaller exploits > in less critical software, and would be calculated as such... Bug severities are probably enough for this purpose. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: goals for hardening Debian: ideas and help wanted
> I suggest it might be better if exploits were each given a quick/approximate > "ranking" in terms of severity (and if the severity is unknown it could be > assigned a default median ranking), so that the algorithm you mention wouldn't > just add number of unplugged exploits, but add them by weight That is a good idea. The Common Vulnerability Scoring System was invented for this purpose: http://en.wikipedia.org/wiki/CVSS Kind regards, Richard -- 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/7f6371fd-0ee0-4f36-8f36-7736f65e7...@vdberg.org
Re: goals for hardening Debian: ideas and help wanted
On Thu, 24 Apr 2014, Paul Wise wrote: On Thu, 2014-04-24 at 02:53 -0007, Cameron Norman wrote: Would the inclusion of more AppArmor profiles be applicable? Thanks, added along with SELinux/etc. I second that. Actually, some time ago I tried using both AppArmor and SELinux, but gave up because it took forever to find legitimate behaviour of all kinds of common packages (most of them standard debian packages) and prepare configuration files for things to work. If debian wants to foster adoption of such security enhancements, it must go to great lengths in making sure that (in order of importance in my humble opinion) 1) all debian-packaged software works (very nearly) out of the box with debian-supported MAC frameworks. It should be very clear that if they don't it's an important bug that needs fixing. For example, such bugs should prevent the inclusion of a package in an official stable release. Or split the main debian archive in two, one that is MAC-ready and one that is not, so each user can decide to only use packages known to work well with debian-supported MAC frameworks. 2) for each debian-supported MAC framework there should be an expert team which should a) help package maintainers learn how to create and include appropriate configuration files so that their package works with the MAC framework b) create some tools (debhelper-like?) to make it relatively easy to find the minimum access rights a package needs and implement them in a configuration file c) define appropriate "style" guidelines to make configuration files as readable and maintainable as possible. All of this is going to be a lot of work at the beginning, but it will quickly decrease as more and more package maintainers get familiar with MAC frameworks. 3) there should be a category of packages in contrib which just contain configuration files for commonly used non-free software. Such configuration files should be audited by the appropriate expert teams before acceptance, to make sure they do not grant unnecessary access privileges. Until at very least point 1) is fulfilled, I doubt there will be widespread adoption of MAC frameworks, except for very specialised systems for which the amount of effort in setting them up is limited. General purpose computers (i.e. the ones in a pool of computers available for PhD students at a University, which must have a lot of packages installed for general use) will remain out of the question. Bye Giacomo -- _ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- 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/alpine.deb.2.10.1404241121540.8...@capitanata.oa-cagliari.inaf.it
Re: goals for hardening Debian: ideas and help wanted
On Thu, Apr 24, 2014 at 11:45:46AM +0200, Giacomo Mulas wrote: > On Thu, 24 Apr 2014, Paul Wise wrote: > >>Would the inclusion of more AppArmor profiles be applicable? > >Thanks, added along with SELinux/etc. > I second that. Actually, some time ago I tried using both AppArmor and > SELinux, but gave up because it took forever to find legitimate behaviour of > all kinds of common packages (most of them standard debian packages) and > prepare configuration files for things to work. If debian wants to foster > adoption of such security enhancements, it must go to great lengths in > making sure that (in order of importance in my humble opinion) > 1) all debian-packaged software works (very nearly) out of the box with > debian-supported MAC frameworks. It should be very clear that if they don't > it's an important bug that needs fixing. For example, such bugs should > prevent the inclusion of a package in an official stable release. Or split > the main debian archive in two, one that is MAC-ready and one that is not, > so each user can decide to only use packages known to work well with > debian-supported MAC frameworks. The apparmor policies in Debian apply a principle of minimal harm, confining only those services for which someone has taken the time to verify the correct profile. There are obviously pros and cons to each approach to MAC, which I'm not interested in arguing about; but one of the pros of the approach taken for apparmor is that all software *does* continue to work out of the box. If you found it otherwise, I think you should be filing a bug report against apparmor. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: goals for hardening Debian: ideas and help wanted
On Thu, 24 Apr 2014, Steve Langasek wrote: The apparmor policies in Debian apply a principle of minimal harm, confining only those services for which someone has taken the time to verify the correct profile. There are obviously pros and cons to each approach to MAC, which I'm not interested in arguing about; but one of the pros of the approach taken for apparmor is that all software *does* continue to work out of the box. If you found it otherwise, I think you should be filing a bug report against apparmor. Good to know, actually I had tried apparmor quite some time ago and did not try again. I will give it another spin as soon as I can. However, I do not agree that I should file bugs against apparmor if a debian package does not work properly, it should go to the package manager (and maybe cc to some apparmor expert team). It cannot be the maintainer(s) of apparmor to have to shoulder the effort of creating and maintaining profiles for all debian packages. They may be called in for support, but regular package maintainers should be involved IMHO, otherwise it will never really take off and provide significantly better security. Thanks for the information. Giacomo -- _ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- 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/alpine.deb.2.10.1404241841420.15...@capitanata.oa-cagliari.inaf.it
Bug#745746: ITP: ruby-generator-spec -- Test Rails generators with RSpec
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil * Package name: ruby-generator-spec Version : 0.9.2 Upstream Author : Steve Hodgkiss * URL : https://rubygems.org/gems/generator_spec * License : Expat Programming Lang: Ruby Description : Test Rails generators with RSpec -- 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/20140424173221.12386.53809.report...@ravel.debian.org
Gcc and undefined behavior
Just a quick FYI for anyone who missed it. Following the discussion from a few days ago about Cava (C like language with no undefined behavior), gcc 4.9 is now out[1]. One of the changes there is a runtime check for undefined behavior. Just compile with -fsanitize=undefined, and your program will crash with log if it performs an operation that C/C++ considers to be undefined. Have not tried it myself, but feedback would be great. Shachar [1] http://gcc.gnu.org/gcc-4.9/changes.html
lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Hi, Moving from debian-devel-games to debian-devel@ for opinions about if this lintian warning is OK to override or not, or in general about what to do with lintian warning about minified JS. 2014-04-24 00:33 Bas Wijnen: lintian is right that the file does not have source, but we don't ship that file in the binary -- we link to the canonical file (from jquery package, or something like that), which has the source in clear code, and has other benefits (like avoiding duplication, etc). Yes, I understand that. But the Lintian maintainers know this, too. And still they emit a warning about it. If you want to argue that this is incorrect, that's not a problem, but you should be arguing to the Lintian maintainers (or better, to the project) that they should remove this warning for files not in a binary package. Overriding the warning is equivalent to saying "I know the project thinks that I'm doing it wrong, but they're all idiots". As I wrote, the only time an override is appropriate is when Lintian is mistaken and it is a false positive (and it shouldn't be fixed in Lintian). That is not the case here. This is an intentional warning, and the package rightfully triggers it. I was only interested in this discussion because sdlgfx was mentioned, and I wanted to say that it was not done carelessly or without consideration, and that I don't share your view or your suggestions that we're violating the license or creating any problem by doing this. I don't think that the lintian check should be removed in the general case of source-is-missing. I don't think that it should be an error for minified JS, or that it should be the same error. The rationaly for overriding this in sdlgfx, after depending on binary jquery and using dh_link for the binary packages, is because I think the lintian warning *in this case* is a kind of mistake part and thus can be overriden: a) the minified .js is still source code, by definition. It's interpreted in different implementations of an ISO-approved interpreted language, and it is valid code. Even in obfuscated form, with minor transformations it's probably easier to understand that some other proper source code out there. So it can be argued that this lintian error is not correct, it is source code even if obfuscated, and open to interpretation in any case. Saying that source code is missing for a file that is actually proper source code is a special case and should be treated differently. b) The first lines of the unminified file clearly states the software projects, version, and URLs to get the non-minified versions, so if users want to modify the code, they can go there or take the version from their Debian system. This is vastly different to the normal idea of binaries without sources (blobs of firmware, .swf files, proprietary binaries without source at all). While it's technically obfuscated, it doesn't have all of the disadvantages that other source-less files have. So the lintian error is in fact equating "source-is-missing" with that this actually a practical problem, presumably because it affects user freedom. b) There's value in the warning, in the sense that if one wants to modify the code, one would prefer to use the unminified version -- the source of the source file, and we provide that in the binary packages, which is the main added value of Debian (not the redistribution of the source -- again, as long as it's legal). d) Thus, saying that the source of the file is missing is technically true in the sense that it was generated by another file, in part not true because it's correct and valid source code, saying that it's not the preferred form of modification is true, but then again it points to the unminified version, so it's not trying to hide the source code away from users or hindering freedom in any way. Consequently, the freedom of the user is not diminished in any way, which is (I think) the only reason why free software licenses insist that the source code is present and mentions the bit about "preferred form of modification". So the presence of the file in the source tarball is not diminishing the freedom of users, and the actions proposed by lintian don't enhance user freedom, from my point of view. And as far as I can see, there are no other problematic issues (neither practical nor theoretical) with having the file there. For all of the above, it is my opinion that the whole discussion about it is rather theoretical and pointless; and the dance of repackaging the upstream tarballs in this case, and probably for all uses of jquery, is a waste of time, and Debian users would see more benefits if contributors spent time elsewhere. We will probably do something to fix this lintian error in another way in future uploads, if only to not spend time discussing this. So, the problem is actually solved, the source-less file that lintian complains about is not us
Help wanted: test new shadow source package (login, passwd, uidmap, etc.)
Hello fellow developers, I would like to request your help in testing the new version of the shadow package (that provides login, passwd and such other important or base packages). Debian is upstream for shadow since Nicolas François (with my help) took over the maintenance of shadow back in 2005. Since then, Nicolas, whose expertise in C programming is millions of miles ahead of mine, did a great job in maintaining the package, keeping its bug log low and in general keep it as safe and clean as possible. However since about 2-3 years, Nicolas is much less active in Debian than he was and I'm mostly left alone really maintaining shadow as a Debian package. And thus, the package had very few uploads. Still, last work by Nicolas happened in early 2013 when he worked again on some requested new features, merging in some proposed work by Serge Hallyn. Later on, more enhancements have been proposed by other people, mostly to integrate the support for subuid/subgid. I'd like to thank, here, Eric Biedermann, Serge Hally and Micah Anderson who helped a lot integrating this, as I know nearly nothing about all this stuff. That lead to a new upstream version (4.2) which, unfortunately, Nicolas had no free time to officially publish. Moreover, all this converged roughly during the wheezy freeze and it was of course inappropriate to upload this. Then dust started to pile up again on shadowand all this work remained unpublished. Partly also because my own involvment in Debian decreased and got recentered on thing I really have expertise about. However, I finally took enough time to bring the final touch to a new package for shadow, namely 4.2-1. This package supposedly brings the long awaited new features such ad subuid, subgid, pam_loginuid in login settings,etc. See the complete changelog at the end of this mail. This package just got uploaded to experimental a few days ago and got ACCEPTed (it add a new "uidmap" package) yesterday. However, I'm completely unable to test the new package except its very very basic functions and here is where I need your help. I really have ZERO clue about these new features and I'm anything but a security or code expert. Indeed, I'm not the best suited person to maintain shadow alone but, as of now, I'm the last one that's left...;-) These new features apparently deserve to be added to the distribution and hopefully jessie but before uploading it to unstable, they need a lot more testing and feedback. So, please, if you're interested in this, or more generally concerned by keeping some of our core packages in goo dcondition, feel free to install the new packages from experimental and test them as you can. Full changelog for the new shadow package (including the damn typos I made here or there, as usual): shadow (1:4.2-1) experimental; urgency=low [ Nicolas FRANCOIS (Nekral) ] * New upstream release. Fixes: - Invalid free() in su fixed by using strdup(). Thanks to Serge Hallyn for the patch. Closes: #691459 - Kill the child process group, rather than just the immediate child; this is needed now that su no longer starts a controlling terminal when not running an interactive shell. Thanks to Colin Watson for the patch. Closes: #713979 - German manpages translation update. Closes: #679152 - Improve login.defs (typographic errors and better format). Closes: #685415 - Russian translation update. Closes: #718356 - Do not assume random() is limited by RAND_MAX. Closes: #677275 - Support C libraries with unknown fields in struct passwd. Closes: #675824 - su: child cleanup is performed before terminating PAM sessions. This avoids anoying "...terminated" messages when PAM module send signal to su during session close. Closes: #670132 - vipw/vigr is checking arguments provided after options. Closes: #677812 - Updated Japanese translation. Closes: #720004 - vipw: Fix error reporting when editor fails. Closes: #688260 * Moved to git: replace Vcs-Git in place of Vcs-Svn and adapt Vcs-Browser. * Add pam_loginuid to login PAM settings. Closes: #677441 * passwd.install: add new subuid.5 and subgid.5 manpages * debian/rules, debian/control, debian/uidmap.install: create new uidmap package containing the new setuid-root binaries newuidmap and newgidmap Set uidmap as priority optional. * debian/login.su.pam: Enable pam_limits by default. Closes: #705301 * debian/rules: Set default editor to sensible-editor for vipw. Closes: #688252 [ Micah Anderson ] * added debian/patches/userns to enable use of subuids, plus some bugfix patches on top of them, patches from Eric Biederman, pulled from Ubuntu. Closes: #739981 * Allow LXC devices (lxc/console, lxc/tty[1234]) in securetty.linux * Update documentation of UMASK: Explain that USERGROUPS_ENAB will modify this default for UPGs. (Closes: #583971) * login.postinst: install a default /etc/subuid
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Correction: 2014-04-24 20:48 Manuel A. Fernandez Montecelo: b) The first lines of the unminified file clearly states the software projects, ^^ minified version, and URLs to get the non-minified versions, so if users want to modify the code, they can go there or take the version from their Debian system. This is vastly different to the normal idea of binaries without sources (blobs of firmware, .swf files, proprietary binaries without source at all). While it's technically obfuscated, it doesn't have all of the disadvantages that other source-less files have. So the lintian error is in fact equating "source-is-missing" with that this actually a practical problem, presumably because it affects user freedom. b) There's value in the warning, in the sense that if one wants to modify the ^^ c), obviously -- Manuel -- 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/2014042420.gb3...@lugh.itsari.org
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) > a) the minified .js is still source code, by definition. Which definition? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#745772: ITP: libdigest-perl-md5-perl -- Perl Implementation of Rivest's MD5 algorithm
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdigest-perl-md5-perl Version : 1.9 Upstream Author : Christian Lackas * URL : https://metacpan.org/release/Digest-Perl-MD5 * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl Implementation of Rivest's MD5 algorithm Digest::Perl::MD5s has the same interface as the much faster Digest::MD5, but unlike that, it is not an interface but a Perl implementation of MD5. Because of this it is slow but it works without C-Code. You should use Digest::MD5 instead of this module if it is available. This module is only useful for - computers where you cannot install Digest::MD5 (e.g. lack of a C-Compiler) - encrypting only small amounts of data (less than one million bytes), e.g. hashing passwords. - educational purposes libdigest-perl-md5-perl is a dependency of libspreadsheet-parseexcel-perl, which uses its internal state in its decryption routines and hence cannot be switched to use Digest::MD5 instead. It will be maintained by pkg-perl. -- 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/1398377739.506663.19744.nullmai...@fschlich.dialup.fu-berlin.de
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
2014-04-24 21:31 Jonas Smedegaard: Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) a) the minified .js is still source code, by definition. Which definition? https://en.wikipedia.org/wiki/Source_code https://en.wikipedia.org/wiki/Minified Basically, no matter how much you contort a script in a scripting language (bash, python, etc), if it can be interpreted by the interpreter of the language (not bytecode or so), it is source code, right? Mildly obfuscated perhaps (but not malicious in this case), but still source. Am I missing something? So the lintian error saying that the source code of a source code file is missing, is a bit... mmm, not the same as a .swf file, or a compiled binary, or firmware blobs without source. BTW, I don't know JS (other than for similarity with other languages), but out of curiosity I tried this from node-uglify package and it looks prettier and more readable than some Python code (not to speak about Fortran) that I see everyday, or 30K line 'configure' scripts. Basically it's missing comments and most original object/variable names, but member/method names of common libraries make the code more or less easy to follow -- if you somehow cannot go to grab the unminified jquery version for whatever reason. $ uglifyjs --beautify jquery.js The points are: - what is the difference between minified JS and 'configure' scripts in source packages (random example), when the .in/.ac that generated it is not in the source package, or the autotools versions which generated it are not present in the package, possibly never packaged in Debian, or not shipped in the same release? Users also lack the source code of those files in that case. - and more importantly, what is the benefit (freedom-wise, or other) for our users if we maintainers spend time repackaging the source in cases of well known files like JQuery, which are: a) present in Debian, b) that we don't ship in our binary packages(if we depend+dh_link, as we did with sdlgfx), c) when it's clear for users who could possibly want to modify the jquery script where they can go if they want to modified the minified jquery.js that they pick from our source packages? For reference, for those who are not aware, these are the current numbers: http://lintian.debian.org/tags/source-is-missing.html Emitted (non-overridden): 7988, overridden: 763, total: 8751 A sizeable part of which is because of minified JS, and JQuery in particular. I really think that we can make better use of our time that fixing this JQuery thing. Cheers. -- Manuel -- 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/20140424222333.ga5...@lugh.itsari.org
Bug#745773: ITP: libextutils-makemaker-cpanfile-perl -- cpanfile support for EUMM
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libextutils-makemaker-cpanfile-perl Version : 0.06 Upstream Author : Kenichi Ishigaki * URL : https://metacpan.org/release/ExtUtils-MakeMaker-CPANfile * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module adding cpanfile support to ExtUtils-MakeMaker ExtUtils::MakeMaker::CPANfile loads cpanfile in your distribution and modifies parameters for WriteMakefile in your Makefile.PL. Just use it instead of ExtUtils::MakeMaker (which should be loaded internally), and prepare cpanfile. -- 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/1398378816.189783.23031.nullmai...@fschlich.dialup.fu-berlin.de
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Quoting Manuel A. Fernandez Montecelo (2014-04-25 00:23:33) > 2014-04-24 21:31 Jonas Smedegaard: > >Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) > >> a) the minified .js is still source code, by definition. > > > >Which definition? > > https://en.wikipedia.org/wiki/Source_code > https://en.wikipedia.org/wiki/Minified Thanks for clarifying. It might be sensible to include the Debian context - here is an attempt at that: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007247.html You might want to read the surrounding thread as well (to avoid us all repeating too much of it here). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Manuel A. Fernandez Montecelo dijo [Thu, Apr 24, 2014 at 11:23:33PM +0100]: > 2014-04-24 21:31 Jonas Smedegaard: > >Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) > >>a) the minified .js is still source code, by definition. > > > >Which definition? > > https://en.wikipedia.org/wiki/Source_code > https://en.wikipedia.org/wiki/Minified > > Basically, no matter how much you contort a script in a scripting language > (bash, python, etc), if it can be interpreted by the interpreter of the > language > (not bytecode or so), it is source code, right? Mildly obfuscated perhaps > (but > not malicious in this case), but still source. Am I missing something? > > So the lintian error saying that the source code of a source code file is > missing, is a bit... mmm, not the same as a .swf file, or a compiled binary, > or > firmware blobs without source. We have beaten this horse way past the point where we want to continue beating it. "Source" can mean many things. What we need is a "preferred form for modification". It is possible for me, yes, to modify (say, bugfix) a minified JS. It is just very, very hard for me to get it right. You could say that .jar Java files are valid source, because they get interpreted by a virtual machine (which is still just an interpreter — for a language that looks just right compiled code). You can even say that my ARM binaries are source, because they can be interpreteded on QEMU under x86 computers. But that does not let us (developers) modify or bugfix it. And even having a pointer to the upstream project is not enough: We have to ship full sources, both for (part of) our licenses' requirements, and to be able to properly support our projects in the future. If http://some.developer.net/projects/JS-Foo disappears from the Internet, then libjs-foo (which only ships foo.min.js) will no longer be maintainable. > BTW, I don't know JS (other than for similarity with other languages), but out > of curiosity I tried this from node-uglify package and it looks prettier and > more readable than some Python code (not to speak about Fortran) that I see > everyday, or 30K line 'configure' scripts. Basically it's missing comments > and > most original object/variable names, but member/method names of common > libraries > make the code more or less easy to follow -- if you somehow cannot go to grab > the unminified jquery version for whatever reason. If it's missing function and variable names, a skilled developer will have some head-scratching time trying to figure out what a simple function does. And if you suggest minifying a "trivial" file such as query.js... Well, that will ensure everybody you have been away from JS development ;-) -- 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/20140425000719.ga29...@gwolf.org
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
2014-04-25 00:02 Jonas Smedegaard: Quoting Manuel A. Fernandez Montecelo (2014-04-25 00:23:33) 2014-04-24 21:31 Jonas Smedegaard: >Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) >> a) the minified .js is still source code, by definition. > >Which definition? https://en.wikipedia.org/wiki/Source_code https://en.wikipedia.org/wiki/Minified Thanks for clarifying. It might be sensible to include the Debian context - here is an attempt at that: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007247.html You might want to read the surrounding thread as well (to avoid us all repeating too much of it here). This thread in debian-devel (pointed from the one that you link) is also relevant from a couple of years ago: https://lists.debian.org/debian-devel/2012/08/threads.html#00365 Didn't read the full thread, it's late here. I think that I agree with the opinion of Marco, Bernd, Ian, Andreas... just to cite a few in the first few messages. I don't think that we should go and do the tedious work of repack thousands of packages because of this, with no real benefit in terms of freedom (or any other) for our users -- provided that we depend and link to the canonical versions in the binary packages. Was there any conclusion to that thread, anyone knows? Cheers. -- Manuel -- 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/20140425001604.ga9...@lugh.itsari.org
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
2014-04-25 01:07 Gunnar Wolf: And even having a pointer to the upstream project is not enough: We have to ship full sources, both for (part of) our licenses' requirements, and to be able to properly support our projects in the future. If http://some.developer.net/projects/JS-Foo disappears from the Internet, then libjs-foo (which only ships foo.min.js) will no longer be maintainable. BTW, I don't know JS (other than for similarity with other languages), but out of curiosity I tried this from node-uglify package and it looks prettier and more readable than some Python code (not to speak about Fortran) that I see everyday, or 30K line 'configure' scripts. Basically it's missing comments and most original object/variable names, but member/method names of common libraries make the code more or less easy to follow -- if you somehow cannot go to grab the unminified jquery version for whatever reason. If it's missing function and variable names, a skilled developer will have some head-scratching time trying to figure out what a simple function does. And if you suggest minifying a "trivial" file such as query.js... Well, that will ensure everybody you have been away from JS development ;-) To both things above, I don't think that this is different to my example of 'configure' script without corresponding .ac/.in; and I don't think that anybody is thinking about adding lintian errors for that or considering those scripts non-free (??). And yes, honestly, I still prefer that JQuery code than configure scripts :-) And just to be clear, my idea was to avoid repacking with e.g. JQuery or other very well known libraries, for which we have the sources in other Debian package present in every release, and for which we can link the binaries to it (and dpkg-source removing those files, for example). Just doing this for JQuery means to not have to repack hundreds or thousands of packages. Cheers. -- Manuel -- 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/20140425002702.gb9...@lugh.itsari.org
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
* Manuel A. Fernandez Montecelo , 2014-04-25, 01:27: I don't think that this is different to my example of 'configure' script without corresponding .ac/.in; and I don't think that anybody is thinking about adding lintian errors for that or considering those scripts non-free (??). I don't know what makes you think that it's okay to have configure scripts without source. If Lintian doesn't currently check for it, it's only because nobody wrote the code yet. -- Jakub Wilk -- 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/20140425003844.ga6...@jwilk.net
Work-needing packages report for Apr 25, 2014
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 569 (new: 1) Total number of packages offered up for adoption: 137 (new: 4) Total number of packages requested help for: 58 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: vgabios (#745170), orphaned 6 days ago Description: VGA BIOS software for the Bochs and Qemu emulated VGA card Reverse Depends: bochs Installations reported by Popcon: 12432 568 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: downtimed (#745711), offered today Description: monitor of downtime, shutdown, and crashes Installations reported by Popcon: 106 ekg (#745312), offered 4 days ago Description: console Gadu Gadu client for UNIX systems - ncurses UI Reverse Depends: ekg-gtk Installations reported by Popcon: 64 ekg2 (#745311), offered 4 days ago Description: instant messenger and IRC client for UNIX systems Reverse Depends: ekg2 ekg2-dbg ekg2-gnupg ekg2-jabber ekg2-scripting-perl ekg2-scripting-python ekg2-ui-gtk ekg2-ui-ncurses Installations reported by Popcon: 135 gaduhistory (#745317), offered 4 days ago Description: EKG history viewer Installations reported by Popcon: 3 133 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1543 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache fuss-launcher goplay packagesearch Installations reported by Popcon: 79748 athcool (#278442), requested 3467 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 53 balsa (#642906), requested 942 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 820 cardstories (#624100), requested 1095 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 11 chromium-browser (#583826), requested 1425 days ago Description: Chromium browser Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n mozplugger Installations reported by Popcon: 25523 cups (#532097), requested 1783 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers cups-daemon cups-dbg (62 more omitted) Installations reported by Popcon: 139886 debtags (#567954), requested 1543 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2451 fbcat (#565156), requested 1562 days ago Description: framebuffer grabber Installations reported by Popcon: 157 freeipmi (#628062), requested 1064 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev libipmiconsole2 libipmidetect-dev libipmidetect0 (3 more omitted) Installations reported by Popcon: 4856 gnat-4.8 (#539562), requested 2205 days ago Description: help needed to execute test cases Reverse Depends: dh-ada-library gnat-4.8 gnat-4.8-sjlj libgnat-4.8 libgnat-4.8-dbg libgnatprj4.8 libgnatprj4.8-dbg libgnatprj4.8-dev libgnatvsn4.8 libgnatvsn4.8-dbg (2 more omitted) Installations reported by Popcon: 109 gnat-gps (#496905), requested 2065 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 528 gnokii (#677750), requested 677 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1763 gnupg (#660685), requested 794 days ago Description: GNU privacy guard - a free PGP replacement Reverse Depends: 0install-core apt arriero bootstrap-base cdebootstrap cdebootstrap-static cdebootstrap-udeb clamav-unofficial-sigs cloud-utils
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
On Fri, Apr 25, 2014 at 01:27:02AM +0100, Manuel A. Fernandez Montecelo wrote: > I don't think that this is different to my example of 'configure' > script without corresponding .ac/.in; and I don't think that anybody > is thinking about adding lintian errors for that or considering those > scripts non-free (??). Configure is not source. The source is configure.ac/in, but I've never seen a project that ships a generated configure script without also shipping its source. > And just to be clear, my idea was to avoid repacking with e.g. JQuery or other > very well known libraries, for which we have the sources in other Debian > package > present in every release, And that's a very valid point. The minified version is not source, but we do have source in the archive. This means there is no problem for the license, and there is no violation of the DFSG either. It's just a technicality that the source is in a different package. For this case, I think it might be good to fix Lintian so it doesn't complain about it anymore as long as there is a dependency on the package containing the source. There's always the question of whether the shipped version is unmodified, but IMO it is not a problem to assume that it is (unless we know better), at least as long as it isn't used. Thanks, Bas signature.asc Description: Digital signature
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Quoting Bas Wijnen (2014-04-25 02:49:56) > On Fri, Apr 25, 2014 at 01:27:02AM +0100, Manuel A. Fernandez Montecelo wrote: >> And just to be clear, my idea was to avoid repacking with e.g. JQuery >> or other very well known libraries, for which we have the sources in >> other Debian package present in every release, > > And that's a very valid point. The minified version is not source, > but we do have source in the archive. I believe it matters that not only project name but also release version matches between source and minified code. I therefore believe packages shipping minified code must ensure that corresponding source - i.e. same version - is available in Debian. And make sure to adapt if that source is later dropped from the archive (e.g. by upgrading the jquery package to newer upstream release). NB! I am not suggesting to actually do such tedious tracking, only acknowledging that such approach is valid¹. What I suggest is the far simpler approach: strip minified code from source) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Le Thu, Apr 24, 2014 at 08:48:47PM +0100, Manuel A. Fernandez Montecelo a écrit : > > The rationaly for overriding this in sdlgfx, after depending on binary jquery > and using dh_link for the binary packages, is because I think the lintian > warning *in this case* is a kind of mistake part and thus can be overriden: Hi Manuel and everybody, I fully agree. What is the point of calling our collective work a “distribution” if the source code can not be distributed among multiple packages ? Just politely ignore or concisely turn down the criticisms unless they bring something new to the past discussions. If people want to twist your arm, they can go to the technical comitte or pass a GR. However I warn against this: the result will be to have less sourceless files, but not because more tarballs will be cleaned. It will be because packages will be removed from our archive after the maintainers abandon them or Debian altogether. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140425013918.gb30...@falafel.plessy.net
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
Manuel A. Fernandez Montecelo dijo [Fri, Apr 25, 2014 at 01:27:02AM +0100]: > To both things above, I don't think that this is different to my example of > 'configure' script without corresponding .ac/.in; and I don't think that > anybody > is thinking about adding lintian errors for that or considering those scripts > non-free (??). Just FWIW, I didn't reply to this point because it's been many years since I last packaged a project using configure scripts (I just work with languages I am comfortable with, and C is not one of them). As others have pointed, shipping configure without compiling it from the .ac/.in is bad and should be seen as a warning, if not directly as a true bug. -- 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/20140425041959.gc30...@gwolf.org
Re: goals for hardening Debian: ideas and help wanted
On Thu, Apr 24, 2014 at 9:49 AM, Giacomo Mulas wrote: > On Thu, 24 Apr 2014, Steve Langasek wrote: > >> The apparmor policies in Debian apply a principle of minimal harm, >> confining >> only those services for which someone has taken the time to verify the >> correct profile. There are obviously pros and cons to each approach to >> MAC, >> which I'm not interested in arguing about; but one of the pros of the >> approach taken for apparmor is that all software *does* continue to work >> out >> of the box. If you found it otherwise, I think you should be filing a bug >> report against apparmor. > > > Good to know, actually I had tried apparmor quite some time ago and did not > try again. I will give it another spin as soon as I can. > > However, I do not agree that I should file bugs against apparmor if a debian > package does not work properly, it should go to the package manager (and > maybe cc to some apparmor expert team). It cannot be the maintainer(s) of > apparmor to have to shoulder the effort of creating and maintaining profiles > for all debian packages. They may be called in for support, but regular > package maintainers should be involved IMHO, otherwise it will never really > take off and provide significantly better security. Both of you have misunderstood each other. Steve, Giacomo was advocating the creation of profiles/configurations for all debian packages and considering it a serious bug if that was not done. Giacomo, Steve thought that you meant that unconfined applications should work perfectly when the user is using a MAC, and not that they should integrate with the MAC mechanism. So he was trying to explain how AppArmor only interferes with explicitly configured (by the package maintainer or user) profiles, and would not cause any harm to non-confined applications. This is forgivably irrelevant, because you are talking about confined applications. Best regards, -- Cameron Norman -- 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/calzwfrlhuawxatvzeb46jbuvozm54crpxac0ksx_wajx4pd...@mail.gmail.com
