Re: Security concerns with minified javascript code

[Neil Williams]

On Thu, 03 Sep 2015 22:51:50 +0200
Vincent Bernat  wrote:

>  ❦  3 septembre 2015 13:19 -0700, Nikolaus Rath  :
> 
> > 2. Many javascript packages cannot be build from source with the
> > tools in main.
> 
> This is the one I don't agree. For me, pre-minification source is
> source code. If you show the pre-minification version of jQuery, many
> people will believe this is a valid source code (original comments,
> variable names and indentation are here).

... except that what you are referring to there is the "source" as it
appears as an unminified JS file on the filesystem after the upstream
code is packaged by Debian. The JQuery upstream is a set of directives
to include other snippet files which are then further processed into
both the unminified JS that looks like source code and the minified JS
which tends to get used by applications. The "source code" that
everyone talks about is actually not edited by anyone, least of all
upstream, it not used by applications (which embed the .min.js) and it
is not convertible to the source for modification used by JQuery
upstream, so patches to that are of no use to fixing security bugs in
JQuery as packaged in Debian.

JQuery in Debian *does* build from upstream source using only tools
available in Debian main. What it builds from is not usable to
applications, but if a bug is reported in the minified or unminified
JS, the maintainer (together with the JQuery upstream) can prepare a
patch to the source code that is built in Debian to produce a change in
the minified and unminified *generated files* for other applications to
use.

Patching an unminified JS file as it exists on the filesystem from
packaging doesn't actually help anyone, except possibly in debugging the
security hole. Even then, one of the more serious problems with
minification is that it isn't just a process of removing comments and
whitespace, the minifier can inject bugs which are not present in the
unminified version. Using a different minifier can introduce *different*
*unknown* bugs that only affect the version patched to "improve
security".

We really need to think of minifiers as transformational - these are
compilers in many ways.

For those upstreams who have to embed JS not available in Debian, then
the upstream code often cannot be processed in Debian, neither can the
unminified JS be minified into the same .min.js file as embedded due to
a lack of tools in Debian. In that sense, the current lintian
requirements are a hindrance and a mess because they require the
embedding upstream to include "source code" which cannot be converted
to the actual running code using tools in main in a reproducible
manner. Using a different minifier results in an untested and
unverifiable .min.js with no assurance that new bugs have not been
introduced.

This thread isn't principally about how JS packages already in main
actually get built and patched, this is about how upstreams who need to
embed JS not available in Debian can support security fixes to
javascript. Patches which produce a third form of the code which
produces a diff to the buggy version that is massively larger than the
security fix itself will not find favour with the release team or
security team during a release freeze.

The maintainers and upstreams of such packages *need* Debian to come up
with an answer for how their code needs to handle security fixes within
Debian. A way that produces a minimal diff to the released version to
make it practical to review the change to a package already in stable.
A way that absolutely does NOT introduce new bugs. A way that is
exclusively possible using tools available in Debian main. Can we
*please* talk about that now? Please don't leave this until the release
freeze for Stretch is on the horizon. This thread has gone on for ages
with bike-shedding, tippy-toeing around DFSG sidelines and insane ideas
about non-free but with no useful output for those who are actually
trying to fix the *SECURITY PROBLEM*.

There is a fundamental misconception in a lot of these discussions
which drops embedding upstreams right in the toilet. There is a real
problem here and it has nothing to do with whether packages go into
contrib or non-free. It is whether packages embedding javascript can
have sane security support in any part of Debian. Moving stuff to
non-free is *not* a security fix!

The core problem is *not* about legality or "preferred source for
modification" or the DFSG or a move to contrib/non-free - those are
(large) complicating factors. The core problem is how to fix
undiscovered security holes in packages already in Debian stable which
need to embed JS not available in Debian. This is a technical and
packaging problem, not a licence or legal one. We're taking about the
*security* of free software, not whether it is free or not.

> > 3. Software that cannot be build from source with the tools in main
> >must not go in main but into contrib
> 
> I agree. And doing from pre-minification source to mi

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  4 septembre 2015 08:29 +0100, Neil Williams  :

>> > 2. Many javascript packages cannot be build from source with the
>> > tools in main.
>> 
>> This is the one I don't agree. For me, pre-minification source is
>> source code. If you show the pre-minification version of jQuery, many
>> people will believe this is a valid source code (original comments,
>> variable names and indentation are here).
>
> ... except that what you are referring to there is the "source" as it
> appears as an unminified JS file on the filesystem after the upstream
> code is packaged by Debian. The JQuery upstream is a set of directives
> to include other snippet files which are then further processed into
> both the unminified JS that looks like source code and the minified JS
> which tends to get used by applications. The "source code" that
> everyone talks about is actually not edited by anyone, least of all
> upstream, it not used by applications (which embed the .min.js) and it
> is not convertible to the source for modification used by JQuery
> upstream, so patches to that are of no use to fixing security bugs in
> JQuery as packaged in Debian.

The pre-minification source code is so close of the original code that
you will have no trouble to apply any security fix to the
pre-minification source code. Let me take a random source file in the
original source:

 https://github.com/jquery/jquery/blob/2.1-stable/src/queue/delay.js

And the pre-minification source code:

 
https://github.com/jquery/jquery-ui/blob/master/external/jquery-2.1.3/jquery.js#L6894-L6906

> JQuery in Debian *does* build from upstream source using only tools
> available in Debian main. What it builds from is not usable to
> applications, but if a bug is reported in the minified or unminified
> JS, the maintainer (together with the JQuery upstream) can prepare a
> patch to the source code that is built in Debian to produce a change in
> the minified and unminified *generated files* for other applications to
> use.

With the only problem that jQuery as shipped by Debian is currently 1.x
while some applications now require 2.x. And jQuery was just an example.

> Patching an unminified JS file as it exists on the filesystem from
> packaging doesn't actually help anyone, except possibly in debugging the
> security hole. Even then, one of the more serious problems with
> minification is that it isn't just a process of removing comments and
> whitespace, the minifier can inject bugs which are not present in the
> unminified version. Using a different minifier can introduce *different*
> *unknown* bugs that only affect the version patched to "improve
> security".

Exactly like a C compiler which can introduce bugs on its own. And
different C compilers have different bugs. Again:
https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf, 8:3.

> We really need to think of minifiers as transformational - these are
> compilers in many ways.

OK with that.

> For those upstreams who have to embed JS not available in Debian, then
> the upstream code often cannot be processed in Debian, neither can the
> unminified JS be minified into the same .min.js file as embedded due
> to a lack of tools in Debian.  In that sense, the current lintian
> requirements are a hindrance and a mess because they require the
> embedding upstream to include "source code" which cannot be converted
> to the actual running code using tools in main in a reproducible
> manner. Using a different minifier results in an untested and
> unverifiable .min.js with no assurance that new bugs have not been
> introduced.

The JS ecosystem is mature enough to know the problems that may arise
with minifiers and work around them. While using yui-compressor is a bit
risky due to its low use, using uglifyjs should be fine. The
pre-minified JS files usually are prepared to be minified (for example,
when using dependency injections, variables are usually converted to
strings to keep their original names during minification, example
available on request).

> This thread isn't principally about how JS packages already in main
> actually get built and patched, this is about how upstreams who need to
> embed JS not available in Debian can support security fixes to
> javascript. Patches which produce a third form of the code which
> produces a diff to the buggy version that is massively larger than the
> security fix itself will not find favour with the release team or
> security team during a release freeze.

Hopefully, this is not the case. An upstream patch can be transformed
into a patch which can be applied to a pre-minification version
"easily". And the result should be of the same size.

There is not a lot of CVE available to use as examples (I think mostly
because bugs get rarely classified as security bugs in this
ecosystem). After a quick search, the most recent one I am able to find
is CVE-2011-4969. The patch is here:

 
https://github.com/jquery/jquery/commit/db9e023e62c1ff5d8f21ed9868ab6878da2005e9

#+be

Re: Security concerns with minified javascript code

[Neil Williams]

On Fri, 04 Sep 2015 10:07:13 +0200
Vincent Bernat  wrote:

>  ❦  4 septembre 2015 08:29 +0100, Neil Williams
>  :
> 
> > For those upstreams who have to embed JS not available in Debian,
> > then the upstream code often cannot be processed in Debian, neither
> > can the unminified JS be minified into the same .min.js file as
> > embedded due to a lack of tools in Debian.  In that sense, the
> > current lintian requirements are a hindrance and a mess because
> > they require the embedding upstream to include "source code" which
> > cannot be converted to the actual running code using tools in main
> > in a reproducible manner. Using a different minifier results in an
> > untested and unverifiable .min.js with no assurance that new bugs
> > have not been introduced.
> 
> The JS ecosystem is mature enough to know the problems that may arise
> with minifiers and work around them. While using yui-compressor is a
> bit risky due to its low use, using uglifyjs should be fine. The
> pre-minified JS files usually are prepared to be minified (for
> example, when using dependency injections, variables are usually
> converted to strings to keep their original names during
> minification, example available on request).

Actually, that is a great relief. Now this thread is getting somewhere
useful.
:-)
 
> > This thread isn't principally about how JS packages already in main
> > actually get built and patched, this is about how upstreams who
> > need to embed JS not available in Debian can support security fixes
> > to javascript. Patches which produce a third form of the code which
> > produces a diff to the buggy version that is massively larger than
> > the security fix itself will not find favour with the release team
> > or security team during a release freeze.
> 
> Hopefully, this is not the case. An upstream patch can be transformed
> into a patch which can be applied to a pre-minification version
> "easily". And the result should be of the same size.
> 
> There is not a lot of CVE available to use as examples (I think mostly
> because bugs get rarely classified as security bugs in this
> ecosystem). After a quick search, the most recent one I am able to
> find is CVE-2011-4969. The patch is here:
> 
>  
> https://github.com/jquery/jquery/commit/db9e023e62c1ff5d8f21ed9868ab6878da2005e9
> 
> #+begin_src diff
> diff --git a/src/core.js b/src/core.js
> index 694f884..0b99b74 100644
> --- a/src/core.js
> +++ b/src/core.js
> @@ -16,8 +16,8 @@ var jQuery = function( selector, context ) {
>   rootjQuery,
>  
>   // A simple way to check for HTML strings or ID strings
> - // (both of which we optimize for)
> - quickExpr = /^(?:[^<]*(<[\w\W]+>)[^>]*$|#([\w\-]*)$)/,
> + // Prioritize #id over  to avoid XSS via location.hash
> (#9521)
> + quickExpr = /^(?:[^#<]*(<[\w\W]+>)[^>]*$|#([\w\-]*)$)/,
>  
>   // Check if a string has a non-whitespace character in it
>   rnotwhite = /\S/,
> #+end_src
> 
> Let me download a pre-minification version of jQuery 1.6.2:
> 
>  http://code.jquery.com/jquery-1.6.2.js
> 
> Patch applies directly:
> 
> #v+
> $ patch --dry-run jquery-1.6.2.js < cve-2011-4969.patch
> checking file jquery-1.6.2.js
> Hunk #1 succeeded at 37 (offset 21 lines).
> #v-
> 
> This will become more difficult with jQuery 3.x (due to ES6 to ES5
> transformation). But manual adaptation should stay straightfoward
> ("transpilation" only does local transformation).

Are there supported tools which could prevent that difficulty becoming
a problem?

> That's why I consider this pre-minification version as valid source
> code.

That indeed would support a usable security fix - thanks.

> >> > 3. Software that cannot be build from source with the tools in
> >> > main must not go in main but into contrib
> >> 
> >> I agree. And doing from pre-minification source to minified source
> >> is possible with the tools in main (uglifyjs or yui-compressor).
> >
> > Not in a way that reproduces the same .min.js as the original
> > source - unless that is from a package already in Debian and the
> > same minifier is used (with the same options).
> 
> Getting the same min.js is not a goal (we don't try to get the same
> binaries than upstream from source code in any other language, for
> example in Go where upstreams like to provide binaries). Not adding
> bugs would be nice, yes, but the situation is improving upstream (see
> above). -- 

OK. In that case, it might be worth embedding upstreams testing with
using uglifyjs on the unminified JS files included upstream and seeing
if there are (functional) bugs introduced by using that minifier. It
could also be worth asking lintian to change the meaning of the current
warnings so that merely accompanying the minified with the unminified
is not enough, that minification with something like uglifyjs should be
tested and that the maintainer should replace the upstream .min.js
with the output of that known minifier (in much the same way as
dh_autoreconf and for simi

Bug#797988: ITP: cadvisor -- analyzes resource usage and performance characteristics of running containers

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org 
pkg-go-maintain...@lists.alioth.debian.org
Owner: Dmitry Smirnov 

* Package name: cadvisor
  Version : 0.16.0.2-1
  Upstream Author : Google Inc.
* URL : https://github.com/google/cadvisor
* License : Apache-2.0
  Programming Lang: Go
  Description : Analyzes resource usage and performance characteristics of 
running containers
 cAdvisor (Container Advisor) provides container users an understanding of
 the resource usage and performance characteristics of their running
 containers. It is a running daemon that collects, aggregates, processes,
 and exports information about running containers. Specifically, for each
 container it keeps resource isolation parameters, historical resource
 usage, histograms of complete historical resource usage and network
 statistics. This data is exported by container and machine-wide.
 .
 cAdvisor has native support for Docker containers and should support just
 about any other container type out of the box.
 .
 cAdvisor also exposes container stats as Prometheus metrics.


signature.asc
Description: This is a digitally signed message part.

Re: system upgrade by systemd

[Mario Lang]

Marc Haber  writes:

> On Tue, 25 Aug 2015 20:35:30 +0200, Matthias Klumpp  wrote:
>>This is a feature of systemd and PackageKit.
>>See http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
>
> Please disable this for Debian. Not tomorrow, do it today.

+1

-- 
CYa,
  ⡍⠁⠗⠊⠕

Bug#798009: ITP: python-editor -- programmatically open an editor, capture the result

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-editor
  Version : 0.4
  Upstream Author : Peter Ruibal 
* URL : https://github.com/fmoo/python-editor
* License : Apache-2.0
  Programming Lang: Python
  Description : programmatically open an editor, capture the result

 python-editor is a library that provides the editor module for
 programmatically interfacing with your system's $EDITOR. The user can then
 enter a commit message for example.
 .
 Editor first looks for the ${EDITOR} environment variable.  If set, it uses
 the value as-is, without fallbacks. If no $EDITOR is set, editor will search
 through a list of known editors, and use the first one that exists on the
 system. For example, on Linux, editor will look for the following editors in
 order:
  * vim
  * emacs
  * nano
 .
 When calling the edit() function, editor will open the editor in a
 subprocess, inheriting the parent process's stdin, stdout

This is a new dependency of Alembic, which already is in Sid and misses it.

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  4 septembre 2015 09:32 +0100, Neil Williams  :

[Applying patch to pre-minification source]
>> This will become more difficult with jQuery 3.x (due to ES6 to ES5
>> transformation). But manual adaptation should stay straightfoward
>> ("transpilation" only does local transformation).
>
> Are there supported tools which could prevent that difficulty becoming
> a problem?

None that I know of. Note that currently, the problem is quite
theoric. I don't know when jQuery 3.x will be released. I don't think
this will happen soon (but I am quite exterior to this community and not
a real jQuery user myself).

>> That's why I consider this pre-minification version as valid source
>> code.
>
> That indeed would support a usable security fix - thanks.

Great!

>> >> I agree. And doing from pre-minification source to minified source
>> >> is possible with the tools in main (uglifyjs or yui-compressor).
>> >
>> > Not in a way that reproduces the same .min.js as the original
>> > source - unless that is from a package already in Debian and the
>> > same minifier is used (with the same options).
>> 
>> Getting the same min.js is not a goal (we don't try to get the same
>> binaries than upstream from source code in any other language, for
>> example in Go where upstreams like to provide binaries). Not adding
>> bugs would be nice, yes, but the situation is improving upstream (see
>> above). -- 
>
> OK. In that case, it might be worth embedding upstreams testing with
> using uglifyjs on the unminified JS files included upstream and seeing
> if there are (functional) bugs introduced by using that minifier.

That would be quite difficult if we are still in the context of
upstreams embedding their own copy of jQuery. First, some upstreams
don't have any JS-based tests (notably if JS is only an
accessory). Second, when they have them, they are unlikely to cover
jQuery use. Third, I really don't know if they are easy to run. Looking
at Wordpress, I see they need Grunt, but maybe having only qunit would
be fine.

I would be inclined to say "let's see if we get bug reports due to the
minification". I didn't run into those myself. Pau did, but it was quite
some time ago.

> What are the problems likely to be if Debian was to recommend/require
> that:
> "minified javascript is not to be regarded as source code suitable for
> supporting security fixes and needs to be rebuilt from unminified source
> code or replaced with symlinks to minified javascript provided by other
> packages, with dependencies added on those packages. When packages need
> to minify embedded Javascript which is not already packaged in Debian,
> only  minifier should be used and any minified javascript files
> included by upstream must be replaced using the output of 
> minifier."

I am not an expert enough to say that uglifyjs is really the minifier to
go. I would say that this is the most popular one, but that's really
just a hunch. Maybe some input from the Debian Javascript Maintainers
would help.

But I am OK with the idea.

> This excludes the issues of packaging of libjs* packages themselves
> (where the same minifier as upstream is likely to be a significant
> advantage in updating the package) but does provide a solution for the
> actual security concerns of packaged minified Javascript. A handy tool
> to do this would be useful as that would allow interested upstreams to
> test the effects of such a minifier before the upload to Debian.
>
> dh_uglify?

If there is some consensus that pre-minification source code is accepted
as valid source code by DFSG, I could help to get that.
-- 
Writing is easy; all you do is sit staring at the blank sheet of paper until
drops of blood form on your forehead.
-- Gene Fowler


signature.asc
Description: PGP signature

Script to generate common license texts

[Balasankar C]

Hi,

Is there any script which takes abbreviation of a license (like
GPL-3+) as input and generates the license text that can be used in
debian/copyright (80 character wrapped, one space before each line,
paragraph separated with periods - the whole deal.

For example, if the script is named 'genlicense', the command
$ genlicense gpl-3.0+

should give the following output

License: GPL-3.0+
 This program is free software: you can redistribute it and/or modify it
under
 the terms of the GNU General Public License as published by the Free
Software
 Foundation, either version 3 of the License, or (at your option) any later
 version.
 .
 This package is distributed in the hope that it will be useful, but WITHOUT
 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS
 FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
details.
 .
 You should have received a copy of the GNU General Public License along
with
 this program. If not, see .
 .
 On Debian systems, the complete text of the GNU General Public License
version
 3 can be found in "/usr/share/common-licenses/GPL-3".



Is there any script which does this already? If not, can I write one
that supports all DFSG-happy licenses and add it to devscripts?

-- 
Regards
Balasankar C
http://balasankarc.in

Re: Script to generate common license texts

[Carsten Schoenert]

Hello Balasankar,

Am 04.09.2015 um 19:38 schrieb Balasankar C:
> Hi,
> 
> Is there any script which takes abbreviation of a license (like
> GPL-3+) as input and generates the license text that can be used in
> debian/copyright (80 character wrapped, one space before each line,
> paragraph separated with periods - the whole deal.
> 
> For example, if the script is named 'genlicense', the command
> $ genlicense gpl-3.0+
> 
> should give the following output
> 
> License: GPL-3.0+
>  This program is free software: you can redistribute it and/or modify it
> under
>  the terms of the GNU General Public License as published by the Free
> Software
>  Foundation, either version 3 of the License, or (at your option) any later
>  version.
>  .
>  This package is distributed in the hope that it will be useful, but WITHOUT
>  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS
>  FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
> details.
>  .
>  You should have received a copy of the GNU General Public License along
> with
>  this program. If not, see .
>  .
>  On Debian systems, the complete text of the GNU General Public License
> version
>  3 can be found in "/usr/share/common-licenses/GPL-3".
> 
> 
> 
> Is there any script which does this already? If not, can I write one
> that supports all DFSG-happy licenses and add it to devscripts?

I was successful using the cme command [1] from the package
libconfig-model-dpkg-perl [2]  while refreshing the copyright
information for Icedove to create a base for further working. But there
are surly other tools.

[1]
https://ddumont.wordpress.com/2015/04/05/improving-creation-of-debian-copyright-file/
[2] https://packages.qa.debian.org/libc/libconfig-model-dpkg-perl.html

-- 
Regards
Carsten Schoenert

Re: Script to generate common license texts

[Markus Koschany]

Am 04.09.2015 um 19:38 schrieb Balasankar C:
[...]
> Is there any script which does this already? If not, can I write one
> that supports all DFSG-happy licenses and add it to devscripts?
> 

Hi,

You can use a combination of licensecheck (devscripts) and
licensecheck2dep5 (cdbs) to accomplish your task:

licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 >
debian/copyright

I think the output/detection could be improved and a patch to devscripts
is surely welcome.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#798040: ITP: dcmstack -- DICOM to Nifti conversion

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: dcmstack
  Version : 0.6.2
  Upstream Author : Brendan Moloney 
* URL : https://github.com/moloney/dcmstack
* License : MIT
  Programming Lang: Python
  Description : DICOM to Nifti conversion

 DICOM to Nifti conversion with the added ability to extract and summarize
 meta data from the source DICOMs. The meta data can be injected into a
 Nifti header extension or written out as a JSON formatted text file.
 .
 This package provides the Python package, command line tools (dcmstack,
 and nitool), as well as the documentation in HTML format.


This package is necessary for creating datsasets that are fully
compliant with and utilize all features of the BRAIN IMAGING DATA
STRUCTURE standard:

http://bids.neuroimaging.io

This is a new community norm for open-data in neuroimaging research.

This package will be maintained by the NeuroDebian team.

Re: Script to generate common license texts

[Balasankar C]

Hi,
[Don't CC me. I am subscribed to the list]

On വെള്ളി 04 സെപ്റ്റംബര്‍ 2015 11:37 വൈകു, Carsten Schoenert wrote:
> I was successful using the cme command [1] from the package
> libconfig-model-dpkg-perl [2]  while refreshing the copyright
> information for Icedove to create a base for further working. But there
> are surly other tools.
>
> [1]
> https://ddumont.wordpress.com/2015/04/05/improving-creation-of-debian-copyright-file/
> [2] https://packages.qa.debian.org/libc/libconfig-model-dpkg-perl.html
Thanks. Let me take a look at cme and licensecheck2dep5.


-- 
Regards
Balasankar C
http://balasankarc.in

Re: Script to generate common license texts

[Jonas Smedegaard]

Hi Balasankar,

Quoting Balasankar C (2015-09-04 19:38:20)
> Is there any script which takes abbreviation of a license (like 
> GPL-3+) as input and generates the license text that can be used in 
> debian/copyright (80 character wrapped, one space before each line, 
> paragraph separated with periods - the whole deal.

Please beware that debian/copyright strings should reflect the actual 
_verbatim_ text stated by the copyright holders, not any generic 
_boilerplate_ proposed by e.g. the Free Software Foundation.


> Is there any script which does this already? If not, can I write one 
> that supports all DFSG-happy licenses and add it to devscripts?

I fail to see the actual (sensible!) use case for such script.


 - 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: Script to generate common license texts

[Balasankar C]

On ശനി 05 സെപ്റ്റംബര്‍ 2015 12:01 രാവിലെ, Jonas Smedegaard wrote:
> Hi Balasankar,
> 
> Quoting Balasankar C (2015-09-04 19:38:20)
>> Is there any script which takes abbreviation of a license (like 
>> GPL-3+) as input and generates the license text that can be used in 
>> debian/copyright (80 character wrapped, one space before each line, 
>> paragraph separated with periods - the whole deal.
> 
> Please beware that debian/copyright strings should reflect the actual 
> _verbatim_ text stated by the copyright holders, not any generic 
> _boilerplate_ proposed by e.g. the Free Software Foundation.

Yeah. I know that. Why I asked for such a script is that some of the
packages I dealt with just mentioned "Released under XYZ license.
Copyright 20xx MNO" without any explicit license text (they should've,
but they don't) which means they just use the _boilerplate_ license text
that is commonly used. For example, many Ruby gems are Expat licensed
and use boilerplate text.

Being that said, I believe debian/copyright should be manually rechecked
for confirmation as copyright info is one of the things we care most in
Debian. :)
The scripts would just be used to reduce the time in searching for the
_boilerplate_ text in the Internet (or other packages), and that too
only if the upstream doesn't provide any verbatim text.

I fail to provide a general use case where this can be directly applied,
but to share one of my experiences I recently dealt with a package that
was released under W3C license (that only, no verbatim text) and I spent
quite some time searching for the license text to be included in
debian/copyright (not the complete license text, but something like we
have for GPL-3.0+ - the one I mentioned in my original mail)


-- 
Regards
Balasankar C
http://balasankarc.in

Re: Bug#798009: ITP: python-editor -- programmatically open an editor, capture the result

[Jakub Wilk]

* Thomas Goirand , 2015-09-04, 14:30:
python-editor is a library that provides the editor module for 
programmatically interfacing with your system's $EDITOR. The user can 
then enter a commit message for example.

.
Editor first looks for the ${EDITOR} environment variable.  If set, it 
uses the value as-is, without fallbacks. If no $EDITOR is set, editor 
will search through a list of known editors, and use the first one that 
exists on the system. For example, on Linux, editor will look for the 
following editors in

order:
* vim
* emacs
* nano


Don't forget to patch it to make it §11.4-compliant.

--
Jakub Wilk

Re: Security concerns with minified javascript code

[Neil Williams]

On Fri, 04 Sep 2015 17:54:30 +0200
Vincent Bernat  wrote:

>  ❦  4 septembre 2015 09:32 +0100, Neil Williams
>  :
> 
> [Applying patch to pre-minification source]
> >> Getting the same min.js is not a goal (we don't try to get the same
> >> binaries than upstream from source code in any other language, for
> >> example in Go where upstreams like to provide binaries). Not adding
> >> bugs would be nice, yes, but the situation is improving upstream
> >> (see above). -- 
> >
> > OK. In that case, it might be worth embedding upstreams testing with
> > using uglifyjs on the unminified JS files included upstream and
> > seeing if there are (functional) bugs introduced by using that
> > minifier.
> 
> That would be quite difficult if we are still in the context of
> upstreams embedding their own copy of jQuery. First, some upstreams
> don't have any JS-based tests (notably if JS is only an
> accessory). Second, when they have them, they are unlikely to cover
> jQuery use. Third, I really don't know if they are easy to run.
> Looking at Wordpress, I see they need Grunt, but maybe having only
> qunit would be fine.
> 
> I would be inclined to say "let's see if we get bug reports due to the
> minification". I didn't run into those myself. Pau did, but it was
> quite some time ago.

I was thinking primarily about my own upstream at that point, i.e.
somewhere where there are staging or test services available with real
data and users etc. but which are not used for important stuff. I want
my own upstream to be confident that the javascript in the release is
both tested before release and fixable after release. We don't have JS
specific tests but we do have test boxes with a representative dataset
to test all relevant use cases. That's the thing with embedding
upstreams, the software has to do so many other things, the JS is a
helper.

> > What are the problems likely to be if Debian was to
> > recommend/require that:
> > "minified javascript is not to be regarded as source code suitable
> > for supporting security fixes and needs to be rebuilt from
> > unminified source code or replaced with symlinks to minified
> > javascript provided by other packages, with dependencies added on
> > those packages. When packages need to minify embedded Javascript
> > which is not already packaged in Debian, only  minifier should
> > be used and any minified javascript files included by upstream must
> > be replaced using the output of  minifier."
> 
> I am not an expert enough to say that uglifyjs is really the minifier
> to go. I would say that this is the most popular one, but that's
> really just a hunch. Maybe some input from the Debian Javascript
> Maintainers would help.
> 
> But I am OK with the idea.

I'm no javascript expert either, far from it. I can see how these ideas
can fix the distribution problems but whether the changes would
introduce new bugs which the embedding upstream may be unable to
reproduce without adopting the same process themselves, only time will
tell.

> > This excludes the issues of packaging of libjs* packages themselves
> > (where the same minifier as upstream is likely to be a significant
> > advantage in updating the package) but does provide a solution for
> > the actual security concerns of packaged minified Javascript. A
> > handy tool to do this would be useful as that would allow
> > interested upstreams to test the effects of such a minifier before
> > the upload to Debian.
> >
> > dh_uglify?
> 
> If there is some consensus that pre-minification source code is
> accepted as valid source code by DFSG, I could help to get that.

The manpage for such a thing should be clear that it is meant for
packages which need to embed JS which is not available in Debian, not
for packages which are primarily or solely javascript. Maintainers of
javascript packages could be recommended to use a minifier and build
system which is compatible with the upstream for that package so that
upstream fixes and Debian patches can be integrated smoothly.

It just needs to a) remove the .min.js from the debian/*/ directories
specified b) ensure the specified .js file exists c) uglify it and
write that in place of the .min.js and d) fail if any
unrecognised .min.js are left at the end.

I'm happy with a statement in Policy that *binary* packages must not
include minified javascript which has not been handled by dh_uglify,
once it exists. If there is a suitable lead time, then new source
package uploads could also be prohibited from containing minified
javascript.

I'm still unsure that pre-minification source code should be accepted
in all cases, but I'm happy if pre-minification *with a recognised
minify service* is the accepted way to handle the security concerns
around embedded javascript. To be accepted for everything,
pre-minification would need to be "easily" convertible back to the
format used for modification by the maintainers and/or upstream of the
javascript package in all cases. With embedded copies, there is 

Bug#798055: ITP: php-mf2 -- Microformats2 is the simplest way to markup structured information in HTML

[Bhuvan Krishna]

Package: wnpp
Severity: wishlist
Owner: Bhuvan Krishna 

* Package name: php-mf2
  Version : 0.2.12
  Upstream Author : Barnaby Walters 
* URL : http://microformats.org/wiki/microformats-2
* License : MIT
  Programming Lang: PHP
  Description : Microformats2 is the simplest way to markup structured
information in HTML

A pure, generic microformats2 parser — makes HTML as easy to consume as a
JSON APIMicroformats2 is the simplest way to markup structured information in
HTML. Microformats2 improves ease of use and implementation for both authors
(publishers) and developer (parser implementers).

 Microformats2 replaces and supersedes both classic microformats, as well as
incorporates lessons learned from microdata and RDFa.

Re: Script to generate common license texts

[Craig Small]

On Fri, Sep 04, 2015 at 11:08:20PM +0530, Balasankar C wrote:
> Is there any script which takes abbreviation of a license (like
> GPL-3+) as input and generates the license text that can be used in
> debian/copyright (80 character wrapped, one space before each line,
> paragraph separated with periods - the whole deal.
Steal them or use them from dh-make.
$ ls /usr/share/debhelper/dh_make/licenses/
apache  artistic  blank  bsd  gpl2  gpl3  lgpl2  lgpl3  mit

If you just lift them a few :%s/%blah%/this/g in vi or equivalent
and you're done.

 - Craig
-- 
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Re: Script to generate common license texts

[Osamu Aoki]

Hi,

Here is another suggestion ...  use debmake!

On Fri, Sep 04, 2015 at 11:08:20PM +0530, Balasankar C wrote:
> Hi,
> 
> Is there any script which takes abbreviation of a license (like
> GPL-3+) as input and generates the license text that can be used in
> debian/copyright (80 character wrapped, one space before each line,
> paragraph separated with periods - the whole deal.

As others has suggested, just taking care GPL3+ is not worth it and it
should be extracted from the source as verbatim copy.

In that sense, if you use debmake as template generating initial
Debianization tool, it creates such file by scanning all the source fles
and extracting such text into DEP-5 format. (debmake is in testing but
can function in stable if installed via dpkg -i)

Please note it creates just a template copyright file.  Your manual
inspaction and editting is absolute requirement.  (But it should be a
lot easier.)

Osamu

Re: [CTTE #741573] Debian Menu System

[Osamu Aoki]

Hi,

I am happy to hear this but this reminds me to think again ...

On Thu, Sep 03, 2015 at 08:34:14PM -0700, Don Armstrong wrote:
> The technical committee was asked in #741573 to decide an issue of
> Debian technical policy regarding menu regarding the menu system.
> 
>  RESOLUTION 
...

>2. In addition to those changes, the Technical Committee resolves
>   that packages providing a .desktop file shall not also provide a
>   menu file for the same application.

That's good idea in general.  I hope lintian warning should come soon.

This reminds me some DE dependent .desktop file.  Is there any best
practice how to do it for Debian?  KDE app not showing up on GNOME and
vice versa.  How to decide how much .desktop data are NotShowIn for what
environment?

Another question: Is there any list of DE names supporting .desktop
file?  Whitelisting with "OnlyShowIn" entry requires such list.

Maybe we shoyld recommend explicit black list using "NotShowIn" entry
over whitelisting with "OnlyShowIn" entry.

Regards,

Osamu

Re: [CTTE #741573] Debian Menu System

[Matthias Klumpp]

2015-09-05 3:49 GMT+02:00 Osamu Aoki :

> [...]
> >2. In addition to those changes, the Technical Committee resolves
> >   that packages providing a .desktop file shall not also provide a
> >   menu file for the same application.
>
> That's good idea in general.  I hope lintian warning should come soon.
>
> This reminds me some DE dependent .desktop file.  Is there any best
> practice how to do it for Debian?  KDE app not showing up on GNOME and
> vice versa.  How to decide how much .desktop data are NotShowIn for what
> environment?
>

In general: Do not use NotShowIn/OnlyShowIn for most applications.
There are only a few areas where it is actually useful, and this is almost
exclusively configuration tools specific to one desktop environment.


> Another question: Is there any list of DE names supporting .desktop
> file?  Whitelisting with "OnlyShowIn" entry requires such list.
>

You mean the list of registered desktop environments?
Take a look at
http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#onlyshowin-registry



> Maybe we shoyld recommend explicit black list using "NotShowIn" entry
> over whitelisting with "OnlyShowIn" entry.
>

Why that? OnlyShowIn makes usually much more sense, but in general it
heavily depends on the case which of the keys makes the most sense.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: Script to generate common license texts

[Jose-Luis Rivas]

I have used neosnippet for it
https://github.com/ghostbar/vim-snippets/blob/master/snippets/_/licenses.snip

-- 
⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co

Re: [CTTE #741573] Debian Menu System

[Josselin Mouette]

Le samedi 05 septembre 2015 à 10:49 +0900, Osamu Aoki a écrit : 
> This reminds me some DE dependent .desktop file.  Is there any best
> practice how to do it for Debian?  KDE app not showing up on GNOME and
> vice versa.  How to decide how much .desktop data are NotShowIn for what
> environment?

The new policy states these values should be synchronized on the
debian-desktop mailing list. So if in doubt, you should just ask.

> Another question: Is there any list of DE names supporting .desktop
> file?  Whitelisting with "OnlyShowIn" entry requires such list.
> 
> Maybe we shoyld recommend explicit black list using "NotShowIn" entry
> over whitelisting with "OnlyShowIn" entry.

The use case is different.
OnlyShowIn is for tools designed for a specific environment (e.g. a
configuration tool).
NotShowIn is for tools where the maintainers of given environments have
requested not to display such entries. If the tool is not generally
useful to most users having it installed, NoDisplay=true should be used.

OnlyShowIn and NotShowIn are mostly useful for packages that are part of
the default installation, or usually installed as dependencies.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-