Re: the status of gstreamer1.0-plugins-bad

[Fabian Greffrath]

Hi Vincent,

> which is unacceptable from a security and stability point of view.

do you conclude this from the package description?

> One problem is that if this package is installed, then Iceweasel
> automatically uses these plugins (even when not needed, currently
> making it crash[*]), with apparently no way to disable them. IMHO,
> either there should be a way to disable them for some applications,
> or this package shouldn't be in dependencies.

I can confirm the crashes with the package in unstable. However, please
note that gstreamer1.0-plugins-bad is entangled into many simultaneous
transitions at the moment. I guess a simple rebuild in a clean
environment could already help to fix it (fwiw, the package in testing
is build from the same source version and does not crash).

If it helps, a new upstream snapshot has just arrived in experimental
and using this, the crashes disappeared.

 - Fabian


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

Re: Security concerns with minified javascript code

[Paul Wise]

On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote:

> I think reading "preferred form of modification" from the perspective of
> upstream is a useful standard because it handles some edge cases like
> that, and because it feels ethically consistent with free software
> principles.  The goal is that everyone with a copy of the software should
> be on equal footing.  The person distributing the software should have no
> special access to sources that those receiving the software don't get.

Thanks for pointing out that the ideas behind Free Software, "source"
and "preferred form for modification" basically boil down to equality
of access.

> If *no one* has access to anything better than a binary file, then
> possession of that binary file puts you on an equal footing with everyone
> else in the world, which I think is all that we can reasonably ask.

We can of course strongly suggest upstreams not throw away their
source files and not modify generated files, instead preserving the
most expressive or information rich formats.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#797875: ITP: libjs-bootswatch -- themes for Twitter Bootstrap

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-bootswatch
  Version : 3.3.5+2+dfsg1
  Upstream Author : Thomas Park 
* URL : https://github.com/thomaspark/bootswatch
* License : Expat
  Programming Lang: Javascript, CSS, LessCSS, etc.
  Description : themes for Twitter Bootstrap

 Bootswatch is a collection of free themes for Bootstrap. Each theme consists
 of two LESS files. variables.less, which is included by default in Bootstrap,
 allows you to customize these settings. bootswatch.less introduces more
 extensive structural changes.

This is a new dependency for the Horizon OpenStack dashboard.

Re: Bug#797875: ITP: libjs-bootswatch -- themes for Twitter Bootstrap

[Dmitry Smirnov]

On Thursday 03 September 2015 10:55:22 Thomas Goirand wrote:
> * Package name: libjs-bootswatch

Apparently a duplicate of #771384...

-- 
Best wishes,
 Dmitry Smirnov.

---

The Santa myth is one of the most effective means ever devised for
intimidating children, eroding their self-esteem, twisting their
behavior, warping their values, and slowing their development of
critical thinking skills.
-- Tom Flynn, "The Trouble with Christmas"


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

Re: Security concerns with minified javascript code

[Dmitry Smirnov]

On Thursday 03 September 2015 08:47:11 Vincent Bernat wrote:
> Please, publish your own study.

I do not need to publish any studies to be sceptical.


> This number is well known and supported
> by an entity which is likely to have a population large enough to be
> significant.

You've mentioned no links to any studies and I found conclusion the way 
you've expressed it to make little sense...


> Without minification, we'll just ship packages that people won't
> use. Why would I run a crippled installation of Wordpress that will
> drive of part of my users to another competitor?

Sorry but that feels like exaggeration. Maybe it is just my perception but  
but it looks like you are trying to justify a bad practice (minification) 
with remotely related arguments of little weight...

Why not use some pluggable minification plug-ins for Wordpress to control 
minification on run-time (not on build time) and being able to opt it out?

-- 
Regards,
 Dmitry Smirnov.



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

Improving your archive and package system for small package

[Bastien ROUCARIES]

Hi,

In order to improve node situation we need to improve the small
packages problems.

What are the main bottlenet ? What could be done to improve the situation ?

The node small package does not change often so it could be a win to
your archive size.
Moreover if we could solve this problem we could think about small
perl package or even tex package.

Regards

Bastien

PS: no flame war please. I am juste trying to package stuff for grunt
and I have a lot of package in the kB range.

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  3 septembre 2015 21:03 +1000, Dmitry Smirnov  :

>> Without minification, we'll just ship packages that people won't
>> use. Why would I run a crippled installation of Wordpress that will
>> drive of part of my users to another competitor?
>
> Sorry but that feels like exaggeration. Maybe it is just my perception but  
> but it looks like you are trying to justify a bad practice (minification) 
> with remotely related arguments of little weight...

I don't see in which world minification is considered a bad
practice. This is a good practice. All JS are minified to half their
sizes (compared to just gzip) and speed up their evaluation.

> Why not use some pluggable minification plug-ins for Wordpress to control 
> minification on run-time (not on build time) and being able to opt it
> out?

Because nobody want non-minified JS files, like nobody want non-optimized
executables (even if they are easier to debug). You are of course
welcome to implement that into Wordpress if you think this is important.

The security concern at the beginning of this thread also applies fully
to C (https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf, 8:3).
-- 
There's small choice in rotten apples.
-- William Shakespeare, "The Taming of the Shrew"


signature.asc
Description: PGP signature

Bug#797893: ITP: kvmtool -- Native Linux KVM Tool

[Riku Voipio]

Package: wnpp
Severity: wishlist
Owner: Riku Voipio 

* Package name: kvmtool
  Version : 20150903
  Upstream Author : Pekka Enberg, Sasha Levin and others
* URL : 
https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/
* License : GPL-2
  Programming Lang: C
  Description : Native Linux KVM Tool

Kvmtool is a lightweight tool for hosting KVM guests. As a pure
virtualization tool it only supports guests using the same architecture, though 
it
supports running 32-bit guests on those 64-bit architectures that allow this.

Re: Improving your archive and package system for small package

[Jérémy Lal]

2015-09-03 13:36 GMT+02:00 Bastien ROUCARIES :

> Hi,
>
> In order to improve node situation we need to improve the small
> packages problems.
>
> What are the main bottlenet ? What could be done to improve the situation ?
>
> The node small package does not change often so it could be a win to
> your archive size.
> Moreover if we could solve this problem we could think about small
> perl package or even tex package.
>
> Regards
>
> Bastien
>
> PS: no flame war please. I am juste trying to package stuff for grunt
> and I have a lot of package in the kB range.
>

Hi Bastien,

please read
https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-June/010693.html
and what follows.

At this point anyone can help by writing some python code...

Jérémy

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-ment...@lists.debian.org, 
788...@bugs.debian.org

Dear mentors,

  I am looking for a sponsor for my package "caffe"

 * Package name: caffe
   Version : 0.~rc2+git20150902+e8e660d3-1
   Upstream Author : BVLC (BERKELEY VISION AND LEARNING CENTER)
 * URL : http://caffe.berkeleyvision.org/
 * License : BSD-2-Clause
   Section : science

  It builds those binary packages:

 caffe-cpu  - Fast open framework for Deep Learning (Tools, CPU_ONLY)
 caffe-cuda - Fast open framework for Deep Learning (Tools, CUDA)
 libcaffe-cpu-dev - Fast open framework for Deep Learning (LibDev, CPU_ONLY)
 libcaffe-cpu0 - Fast open framework for Deep Learning (Lib, CPU_ONLY)
 libcaffe-cuda-dev - Fast open framework for Deep Learning (LibDev, CUDA)
 libcaffe-cuda0 - Fast open framework for Deep Learning (Lib, CUDA)
 python-caffe-cpu - Fast open framework for Deep Learning (Python2, CPU_ONLY)
 python-caffe-cuda - Fast open framework for Deep Learning (Python2, CUDA)

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/caffe

  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_0.~rc2+git20150902+e8e660d3-1.dsc


  Changes since the last upload:

caffe (0.~rc2+git20150902+e8e660d3-1) experimental; urgency=low

  * Initial release. (Closes: #788539)
  * Modify upstream Makefile:
- Add SONAME: libcaffe.so.0 for libcaffe.so
- Fix rpath issue
  * Modify upstream CMake files:
- Add SONAME: libcaffe.so.0 for libcaffe.so
  * Flush content of ".gitignore" from upstream tarball


  Regards,
   Zhou Mo


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

Re: Improving your archive and package system for small package

[Bastien ROUCARIES]

On Thu, Sep 3, 2015 at 2:26 PM, Jérémy Lal  wrote:
>
>
> 2015-09-03 13:36 GMT+02:00 Bastien ROUCARIES :
>>
>> Hi,
>>
>> In order to improve node situation we need to improve the small
>> packages problems.
>>
>> What are the main bottlenet ? What could be done to improve the situation
>> ?
>>
>> The node small package does not change often so it could be a win to
>> your archive size.
>> Moreover if we could solve this problem we could think about small
>> perl package or even tex package.
>>
>> Regards
>>
>> Bastien
>>
>> PS: no flame war please. I am juste trying to package stuff for grunt
>> and I have a lot of package in the kB range.
>
>
> Hi Bastien,
>
> please read
> https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-June/010693.html
> and what follows.
>
> At this point anyone can help by writing some python code...

I was thinking generally, perl latex python have a lot of small
package. Each language could not come with its own solution. Maybe
creating a tool agregating small debian package in a big one. But
doing something only for javascript is not a solution.

Bastien

> Jérémy
>

Bug#797908: ITP: drf-fsm-transitions -- Django-FSM transitions for Django REST Framework

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: drf-fsm-transitions
  Version : 0.2.0
  Upstream Author : Jacob Haslehurst 
* URL : https://github.com/hzy/drf-fsm-transitions
* License : Expat
  Programming Lang: Python
  Description : Django-FSM transitions for Django REST Framework

 Automatically hook your Django-FSM transitions up to Django REST Framework by
 using the provided viewset mixin. Each transition will be made available
 through its name in the object URL and can be called using POST.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJV6F7WAAoJEGlMre9Rx7W2XvYP/1mmc8twZc9jHXSgOCAgXB6k
7yKsbkycuDaPmpEV+NzV0RPyYxIQEu1BvX4+FGrEX0EyZe7Bmwz3oM8n8FeMJHyP
wZ4VoF/gahhGQSz70/i7J74XyYWyygFGsIwFTspmNWJyudVcyqpJu74n3TBQuKkm
pqp4mgFgAivnOJu9FgaxFyg5rt53OMgQKvtK4bYSQ2e3EeE+dKa36zHd5E1CPJ96
kbGk3GFP2ULSn4Ela3a+x/YnSPRPRW8E2b2M/TbtQUQtO7vVAAQtR07gbBROLZ/6
pZ1Jjc3poKfcAGz4hvcKxSQ7iLxTtCrP1cI/hjqUP+Wv+utTiumjXpGz634jWmRe
XhMhLQYejcxsYIIy7pfJzGSnViQ2syiHqayA7eFHltrI//9f7kNqyAboRk9WYp3W
ct68VL/a27CXXMTHTAoNrLv7w6KWO1av5EUoD3K7A/72ob1tbwKm5X74AkdKaFfL
uPjPE6KHsDzFUcVIS2q96EKDRtdusyFqTNE7Ew9NHeMzG2G0Zu7I6ve8MIHsdF+m
SJqcqVxKjrvEdgdeFRgJKe4n6gxwT/FwGmdruHkMjyNYu3TaA4k3Zv0vGVXFVddh
/iVaxSD5dt+nNFc9363lEXnAf5PXmiFMm6Wg5fEZ5bzcgL0U/nGquIUB4RCGMtAr
4+SC2Q01X1cMoxMx8CDL
=OTlU
-END PGP SIGNATURE-

Bug#797909: ITP: django-downloadview -- efficient static file serving with Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: django-downloadview
  Version : 1.8
  Upstream Author : Benoît Bryon 
* URL : https://github.com/fladi/django-downloadview
* License : BSD-3-clause
  Programming Lang: Python
  Description : efficient static file serving with Django

 django-downloadview makes it easy to serve files with Django:
 .
  * manage files with Django (permissions, filters, generation, ...);
  * files are stored somewhere or generated somehow (local filesystem,
remote storage, memory...);
  * django-downloadview helps to stream the files with very little
code;
  * django-downloadview helps to improve performances with reverse
proxies, via mechanisms such as Nginx’s X-Accel or Apache’s
X-Sendfile.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJV6GAMAAoJEGlMre9Rx7W2fIYP/3mV/bB6l4Nb5R3KEgWXjtkm
1Wq+vznWND/odlzK2ElFonrBROnDa7EtoYOT138bDjMcGztdho34KaYbLFODykxk
MDZ4at4mQKwuXqg9cjquYx5iwX2AMDUjuLqUcRn4o7hiRki9pqAvhakPFyfs6gjV
zW6KZU9jlMvckmbkMWWugXq923zsJSXi7foHlwRigQuXCEq0qp91tXTCgWK7p1eq
a/ve4PCxkjFmADp0WTFqyCcm1xqLOICFKjtQefxAsOsoZ40qyII/qQyIegYkhNrm
iA9zzGhxJOKqZAyg4Hp1TDlSMyF8eh395pYCfReu9m+sjwCDynRDJxAT/ysLHPTY
78zEA0jgO7wdK8ngam238OlzAz7td0EG9e/dlIiv9nGnfvSz7jWk1UITRqgE2I/S
I4yOrgDlNTEWWVQ7vckQkkpyi5+d1LREe/WdX9dnxrMFdXitTjNuQ/uzFVZ5a4nX
4sOFUmYd9Hj12zY6BwCihDm5A80lcIjkKCB4XM6sfuWH8gJmXvQYploVFxCDc8Kx
DlmzCHrhOXxMBy6odKyUFdM0zEGxCf1JHh9GCHGxnYL6s9ftX0HQgeAJetV4dAr1
n2asJ2q5y/u9RKPfpvK9yUP3nDnmTDEFMGza74Rl35cuB7iXKBSNzN1t1drA5wnb
S2w8bybnwXNTuD/3Y6GC
=rEvl
-END PGP SIGNATURE-

Re: Improving your archive and package system for small package

[Jose-Luis Rivas]

On 03/09/15, 03:13pm, Bastien ROUCARIES wrote:
 
> I was thinking generally, perl latex python have a lot of small
> package. Each language could not come with its own solution. Maybe
> creating a tool agregating small debian package in a big one. But
> doing something only for javascript is not a solution.
> 
> Bastien

The use of small packages in nodejs is different to that on perl, latex
and python. They are very used and they are way too much. There are
several solutions for the same problem and everyone uses a different
one.

I use nodejs everyday in my work and opensource projects and I refuse to
package them into debian precisely by this reason.

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


signature.asc
Description: Digital signature

Re: Improving your archive and package system for small package

[Adrien CLERC]

Le 03/09/2015 13:36, Bastien ROUCARIES a écrit :
> Hi,
>
> In order to improve node situation we need to improve the small
> packages problems.
>
> What are the main bottlenet ? What could be done to improve the situation ?
>
> The node small package does not change often so it could be a win to
> your archive size.
> Moreover if we could solve this problem we could think about small
> perl package or even tex package.
>
Hi,

This may have been discussed before, but could we achieve something like
this with virtual package?
For example, define virtual packages for every small package
(nodejs-myfunkyoneliner) that is only provided by a bigger package (e.g.
nodejs-libraries1, so we can split those bigger packages), containing a
compilation of those librairies.
Then, another packaged software can just depends on those virtual
packages. The real files will be installed with potentially uneeded
other ones, but it will reduce overhead.

This may be a bad idea, though. I'm not a dpkg expert.

Adrien

Re: Improving your archive and package system for small package

[Jonas Smedegaard]

Quoting Bastien ROUCARIES (2015-09-03 13:36:15)
> In order to improve node situation we need to improve the small 
> packages problems.
> 
> What are the main bottlenet ? What could be done to improve the 
> situation ?
> 
> The node small package does not change often so it could be a win to 
> your archive size.
> Moreover if we could solve this problem we could think about small 
> perl package or even tex package.

Seems Osamu Aoki is working on at least part of the puzzle: 
https://bugs.debian.org/797045


 - 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#797914: ITP: jasp -- graphical statistical package designed to familiar to users of SPSS

[Jonathon]

Package: wnpp
Severity: wishlist
Owner: Jonathon 

* Package name: jasp
  Version : 0.7.1.12
  Upstream Author : Jonathon Love 
* URL : https://jasp-stats.org
* License : AGPL
  Programming Lang: C++, JavaScript, R
  Description : graphical statistical package designed to familiar to users 
of SPSS

 JASP is a graphical statistical package designed to familiar to users of SPSS, 
which provides both classical and Bayesian statistical methods

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Lars Wirzenius dijo [Wed, Sep 02, 2015 at 09:32:12AM +0300]:
> However, I want to raise the point that upstreams do not always make
> sensible decisions, and if they don't, it's good to raise that with
> them. For example, there was recently an ITP bug for
> node-number-is-nan. Upstream source code is at
> https://github.com/sindresorhus/number-is-nan, and the whole package
> boils down to these four lines of code:
> 
> 'use strict';
> module.exports = Number.isNaN || function (x) {
> return x !== x;
> };
> 
> (https://github.com/sindresorhus/number-is-nan/blob/master/index.js)
> 
> If something or someone needs this, we should package it, and it seems
> Grunt needs it. However, it doesn't seem sensible to have a package
> for every one-liner Javascript function, either in Debian or upstream.
> (...)

I agree, having all the boilerplate and infrastructure that make up a
package makes very little sense in this case. We have several packages
that are made up of bits from different origin, but linked with a
common target. The first example that comes to my mind is devscripts
(which, yes, has important peculiarities, such as being mostly written
by Debian-people as upstreams), but others can be mentioned
(i.e. emacs-goodies, texlive-generic-extra, etc.)

Such a package could be created for all such Javascript snippets which
present a ES6→ES5 "transpiler" (I still don't believe in such a term),
i.e. things such as what's mentioned at:

   https://github.com/addyosmani/es6-equivalents-in-es5

   
http://www.agile-environment.com/blog/fox-on-software/2015-04-06-es6-coffeescript-part-1

That is, one package that would allow using tricks such as Perl
(>=5.10)'s "use feature" and "no feture" tricks that allow for Perl6
idioms.

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Vincent Bernat dijo [Wed, Sep 02, 2015 at 09:47:23AM +0200]:
> If you talk about uglifyjs or the like, it is already packaged and
> doesn't solve all the problems we have (see my message to Odyx,
> ).
> 
> If you talk about Grunt, Grunt comes with a lot of plugins (and does
> almost nothing without those) and each upstream will require different
> plugins with different versions (Grunt plugin versions are evolving
> fast). See the tree I posted for jQuery 3.x in
> . All this dependency chain is maintained
> by a variety of upstreams with different release schedules and goals.

This sounds quite similar to the situation we had with Rails (might
still have it, but I cannot say for sure, as I'm not much involved
with it anymore). Rails packages a set of Ruby libraries, each of
which has its schedule and versions.

Rails' developers "curate" such libraries, write some glue between
them (sometimes even take over their whole development), and come up
with "versions". Those versions have a stable set of libraries
presented together.

Of course, that does not (completely) solve the mess we have to deal
with when packaging Ruby, as each developer wants her code to work
with wildly differing versions of the involved "gems", and... and...

Sigh :-) You know what I mean.

But anyway — Grunt can be seen as a whole. If you just see it as a
collection of plugins, packaging them becomes just a pointless
PITA. We just cannot have different versions of hundreds of projects
in Debian and expect to maintain a decent code quality. Bad Things
(i.e. software vulnerabilities) can and will happen, and as Neil
Williams mentioned earlier on this thread, keeping track of all those
embedded code copies becomes an exponentially hard task.

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 03, 2015 at 08:47:11AM +0200, Vincent Bernat wrote:
> Without minification, we'll just ship packages that people won't
> use. Why would I run a crippled installation of Wordpress that will
> drive of part of my users to another competitor?

Because you know you have the right and the ability to be a part of the free
software community that created the software.  That is why you are running
Debian and don't have contrib or non-free in your sources.list.

- From your mails it is clear that you don't care much about that.  That is 
fine.
I recommend that you do put contrib and non-free in your sources.list.  You'll
get all the non-crippled programs that we ship, but there's no guarantee that
you will be able to get the source, or compile it if you can get it.

To keep all our users happy, not just the ones who want contrib and non-free
enabled, please put things that people like me don't want to see in there, not
in main.  (Of course, fixing the problem is even better, but if you're not
willing to do that work, then at least don't put the software in main.)

> We don't turn C into an interpreted language because it would be easier
> to inspect the resulting binaries.

We do remove non-free content (or things that need non-main content) from
upstream sources and I'm sure some people consider that crippling as well.
There are two options: they are the maintainer and really like the stuff: they
can package it for contrib or non-free.  They are not: they can go use a
distribution that doesn't care as much about freedom as Debian does.

There is also a non-option: they break the rules we have set up for main, with
the excuse that otherwise our users would be unhappy.  That is what you
suggest.  We don't do that.  People who don't like our rules shouldn't be using
Debian.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV6IHpAAoJEJzRfVgHwHE6zHoP/38VNuzOKVDbCeZCpvOBItJh
EFCTkNBxQTBCmTrj7JArMYN1CKUVkkb+qKMLex2xxjfPIdydTeT+bOYHIBIWBNHm
a2ZNEN+0zg5cxte3D8m54YYFBfbaKuFPE9/jqkSWkWAIBjt9p84G663q5S8o6P4X
dqwLTvOjVgPc0BZ6j6Bo7s8BQiFW/UBIyMgsN32HlLhRyYOG7TErkOwdSmFqq6tw
GZEh9GMvRAw/3yTPVoZsJ9RyWKP5TpTRuGZe69CAaTmWDRtuq33O4JSzhmW+hdd7
T8jSAhrhpVe92AGo8qZodF/WLU61J4LbpLg42r9xhmKVu/OkrC7NdHhKK6ypwh6O
MNgxh4jf4MUMysCBuL2F2Fb1kcHb5ezvNq71IzeOIU0ry3EHDSnUlJQGbdwhiqrr
9xTEGeGsSgmUqKR2/twZx6+lk59/sto9WyEpZ21wdKk8zRU+cXaJZC4VREHYky0i
YDORHnt3yYBJnu+C5eYlgNZbXUObOrB2CedjVeLcBIGP9sHwAvOY2A/ZPs1SrseO
y8zc163CjXaZ7ETjcoTT6DGlbT1FUmHwsmOrt34ODERl+GZPX6GbrbiPdBklPsxS
/XTZk61I8SS2c25Bt1QOI+aG/70KKhGqTkY3qd/pT+w7EGEWeE6FqnKAzM/+X1hw
t6yOkF8zT3TQIIfe+918
=JSxd
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Russ Allbery]

Paul Wise  writes:
> On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote:

>> If *no one* has access to anything better than a binary file, then
>> possession of that binary file puts you on an equal footing with
>> everyone else in the world, which I think is all that we can reasonably
>> ask.

> We can of course strongly suggest upstreams not throw away their
> source files and not modify generated files, instead preserving the
> most expressive or information rich formats.

Indeed, and for images this is frequently a problem.  People construct
them using various rich data and then flatten them down to JPEGs or PNGs
and throw away all the other information.

Of course, even if they keep it, it's often Photoshop files, which is only
of marginal utility  :/

-- 
Russ Allbery (r...@debian.org)   

Re: Security concerns with minified javascript code

[Marvin Renich]

* Neil Williams  [150902 14:33]:
> Minified isn't source for modification... [large snip]

I don't believe I have disagreed with anything you said in the snipped
text.  I certainly did not mean to.  I said that minified JS can only go
in main if both the source and the tools to build it are also in main.
I also said that this is a hard problem to tackle, but Debian should
tackle it (which is what this thread appears to be doing) instead of
ignoring it.

> On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich  wrote:
> > This whole thread is about...
> 
> It's not about contrib or main, that is roughly equivalent to thinking
> that every DFSG problem looks like a nail because all you have available
> is a large hammer instead of solving the problem inside main.

First, I will retract the phrase "this whole thread"; I should have said
the points in the thread to which I was responding.

Second, I was not proposing any solution to the problem or agreeing with
anyone's solution.  All of my posts were about exposing incorrect
interpretations of the term "source" in the DFSG.  I think, though I'm
not quite sure, that I replied to posters on both sides of the debate (a
large part of this thread does appear to debate what is required for
minified JS to go in main).

Perhaps my posts were misinterpreted as endorsing or opposing a specific
solution?

...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

* Bas Wijnen  [150902 17:36]:
> > On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich  wrote:
> > > No, "A preferred form" is what upstream uses.  The DFSG does not use
> > > the term "THE preferred form", and I believe that was wise.
> 
> The DFSG doesn't define source at all.  There seems to be consensus (you're 
> the
> only one who doesn't seem to agree) that the definition from the GPL is a good
> one, and that does say "the".

Quoting from [1]:
  The process involves human judgement. The DFSG is an attempt to
  articulate our criteria. But the DFSG is not a contract.

People keep trying to use "the preferred form for modification" as a
rule.  This is wrong.  The rest of the paragraph quoted above should
also be read.

I do strongly believe that "preferred form for modification" is a good
test to apply, but it is not an absolute.  I also believe that sometimes
there is more than one form of source that can satisfy the DFSG.  A
simple example is the .xcf/.png/.ico example I gave in a previous
message.  This is why I disagree with using "THE" (implying only one)
instead of "A" (implying one of many).

> > > There can be multiple "preferred forms" for some software, and all are, in
> > > my opinion, acceptable by the DFSG.  The real question is whether it is
> > > reasonable to expect someone who wishes to modify the software to consider
> > > the form "source".
> 
> I disagree partly.  It is possible to copy a generated file and use that as
> source.  IMO that isn't the case until there have actually been made
> modifications to that file, though.  If an upstream (which doesn't need to be
> the original upstream) actually uses a file to make modifications, an argument
> can be made that this format is source.
> 
> At the same time, we should try to convince upstreams that do such a thing to
> stop it; it causes code duplication and a (security) support nightmare.

I'm not sure how that is relevant to what I said.

> "Someone might think they can make modifications to this file" is much too
> broad; for some modifications a hex editor is good enough.  And in some cases
> that is totally reasonable, such as an executable for which you don't have
> source.  That doesn't make binary exectutables source.

That is not at all what I said.  To paraphrase, using a circular
definition, if I can _reasonably_ _expect_ most other people to agree
that it is source, then that is a very good indication that it is
source.

...Marvin

[1] https://people.debian.org/~bap/dfsg-faq.html#testing

Re: Security concerns with minified javascript code

[Marvin Renich]

* Neil Williams  [150902 14:15]:
> On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich  wrote:
> > It is presumed that upstream already has what it considers "source";
> > in the case of this thread, that is minified JS.
> 
> Actually, not. Source, for upstream of JQuery at least, is a set of
> directives to include files into a non-minified jquery.js which is then
> minified as part of the build in Debian.

I stand corrected.

> There are three players:
[large snip]
> It is a complete mess - with the embedding upstreams lost in the middle
> with no idea of what they can do to avoid getting in the way.

I completely agree.

...Marvin

Bug#797928: ITP: python-cbor -- Python Implementation of RFC 7049. Concise Binary Object Representation (CBOR)

[Agustin Henze]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org


   Package name: python-cbor
Version: 0.1.21
Upstream Author: 2014-2015 Brian Olson
URL: https://bitbucket.org/bodhisnarkva/cbor
License: Apache-2.0
Description: Python Implementation of RFC 7049. Concise Binary Object
Representation (CBOR).
 CBOR is comparable to JSON, has a superset of JSON’s ability, but serializes
 to a binary format which is smaller and faster to generate and parse.
 .
 The two primary functions are cbor.loads() and cbor.dumps(). This library
 includes a C implementation which runs 3-5 times faster than the Python
 standard library’s C-accelerated implementanion of JSON. This is also includes
 a 100% Python implementation

-- 
TiN

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  3 septembre 2015 17:22 GMT, Bas Wijnen  :

> Because you know you have the right and the ability to be a part of the free
> software community that created the software.  That is why you are running
> Debian and don't have contrib or non-free in your sources.list.
>
> From your mails it is clear that you don't care much about that.

Repeating that in each of your email is quite hostile. Please stop
saying that I don't care. I care. I just don't agree with you.
-- 
The first thing we do, let's kill all the lawyers.
-- Wm. Shakespeare, "Henry VI", Part IV


signature.asc
Description: PGP signature

Bug#797935: ITP: golang-gopkg-gcfg.v1 -- read INI-style configuration files into Go structs

[Dmitry Smirnov]

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

* Package name: golang-gopkg-gcfg.v1 AKA golang-googlecode-p-gcfg
  Version : 0.0~git20150817.0.5866678-1
  Upstream Author : Péter Surányi
* URL : https://gopkg.in/gcfg.v1
* License : BSD-3-clause
  Programming Lang: Go
  Vcs-Browser : 
https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-gcfg.v1.git
  Description : read INI-style configuration files into Go structs
 gcfg reads "INI-style" text-based configuration files with "name=value"
 pairs grouped into sections (gcfg files). Gcfg supports user-defined types
 and subsections.


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

Re: Security concerns with minified javascript code

[Nikolaus Rath]

On Sep 03 2015, Vincent Bernat  wrote:
>  ❦  3 septembre 2015 17:22 GMT, Bas Wijnen  :
>
>> Because you know you have the right and the ability to be a part of the free
>> software community that created the software.  That is why you are running
>> Debian and don't have contrib or non-free in your sources.list.
>>
>> From your mails it is clear that you don't care much about that.
>
> Repeating that in each of your email is quite hostile. Please stop
> saying that I don't care. I care. I just don't agree with you.


As a (mostly) passive observer of this thread, I have to agree with Bas
that what you're saying (and what not saying) in your other emails does
seem to imply that you don't care.

(And why is it hostile to say that someone doesn't care about something?
I don't care about a lot of things, and I wouldn't consider it hostile
for people to point that out).

Can you maybe clarify which of the following statements you don't agree with?

1. Minified javascript isn't source
2. Many javascript packages cannot be build from source with the tools
   in main.
3. Software that cannot be build from source with the tools in main
   must not go in main but into contrib


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Improving your archive and package system for small package

[Josh Triplett]

Jonas Smedegaard wrote:
> Seems Osamu Aoki is working on at least part of the puzzle:
> https://bugs.debian.org/797045

Merging multiple sources *really* shouldn't be necessary.  And the
metadata for those sources will vary, so that likely won't save that
much space.

Perhaps we should add a few more things to common-licenses, or figure
out if our packaging metadata could be further reduced or de-duplicated.
It should be possible to package a 1kB library without several kB of
overhead.  But even if we have to pay that overhead, so be it; we have
tens of thousands of packages already, what's a few hundred more tiny
JavaScript packages as long as they're actually used?

- Josh Triplett

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  3 septembre 2015 13:19 -0700, Nikolaus Rath  :

>>> Because you know you have the right and the ability to be a part of the free
>>> software community that created the software.  That is why you are running
>>> Debian and don't have contrib or non-free in your sources.list.
>>>
>>> From your mails it is clear that you don't care much about that.
>>
>> Repeating that in each of your email is quite hostile. Please stop
>> saying that I don't care. I care. I just don't agree with you.
>
>
> As a (mostly) passive observer of this thread, I have to agree with Bas
> that what you're saying (and what not saying) in your other emails does
> seem to imply that you don't care.
>
> (And why is it hostile to say that someone doesn't care about something?
> I don't care about a lot of things, and I wouldn't consider it hostile
> for people to point that out).

It's hostile because it depicts as someone that shouldn't be a DD
(because we abided [abode?] to the social contract).

> Can you maybe clarify which of the following statements you don't agree with?
>
> 1. Minified javascript isn't source

I agree, minified JS isn't source.

> 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).

> 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).
-- 
Avoid multiple exits from loops.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Improving your archive and package system for small package

[Jonas Smedegaard]

Quoting Josh Triplett (2015-09-03 22:26:12)
> Jonas Smedegaard wrote:
>> Seems Osamu Aoki is working on at least part of the puzzle:
>> https://bugs.debian.org/797045
>
> Merging multiple sources *really* shouldn't be necessary.  And the 
> metadata for those sources will vary, so that likely won't save that 
> much space.
>
> Perhaps we should add a few more things to common-licenses, or figure 
> out if our packaging metadata could be further reduced or 
> de-duplicated. It should be possible to package a 1kB library without 
> several kB of overhead.  But even if we have to pay that overhead, so 
> be it; we have tens of thousands of packages already, what's a few 
> hundred more tiny JavaScript packages as long as they're actually 
> used?

For the record: I totally agree with above.  I have never seen any 
measures of actual problems caused by tiny-content packages - and if 
that really is a problem then I suspect metapackages and transitional 
packages are even bigger problem...

...that said, I responded to someone indicating interest in improving 
something in Debian, and I want to support that initiative because even 
though this *shouldn't* be necessary, it currently is - because some in 
Debian, including ftpmsters, consider it necessary.


 - 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

Work-needing packages report for Sep 4, 2015

[wnpp]

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: 669 (new: 3)
Total number of packages offered up for adoption: 181 (new: 2)
Total number of packages requested help for: 49 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   fabric (#797593), orphaned 3 days ago
 Description: Simple Pythonic remote deployment tool
 Installations reported by Popcon: 381

   openbgpd (#797218), orphaned 6 days ago
 Installations reported by Popcon: 1

   vmpk (#797535), orphaned 3 days ago
 Description: Virtual MIDI Piano Keyboard
 Installations reported by Popcon: 383

666 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:

   gtkmathview (#797509), offered 3 days ago
 Reverse Depends: libgtkmathview-bin libgtkmathview-dev
   liblablgtkmathview-ocaml liblablgtkmathview-ocaml-dev
 Installations reported by Popcon: 4977

   masqmail (#797301), offered 5 days ago
 Installations reported by Popcon: 38

179 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 2040 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache goplay muon muon-discover packagesearch
 Installations reported by Popcon: 51930

   athcool (#278442), requested 3964 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 32

   awstats (#755797), requested 407 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4172

   balsa (#642906), requested 1439 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 802

   cardstories (#624100), requested 1592 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 6

   cups (#532097), requested 2280 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (67 more omitted)
 Installations reported by Popcon: 154190

   debtags (#567954), requested 2040 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2068

   developers-reference (#759995), requested 369 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 16241

   ejabberd (#767874), requested 304 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib
 Installations reported by Popcon: 803

   fbcat (#565156), requested 2059 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 176

   freeipmi (#628062), requested 1561 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev
   libfreeipmi16 libipmiconsole-dev libipmiconsole2 (6 more omitted)
 Installations reported by Popcon: 6455

   gnat-gps (#496905), requested 2562 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 525

   gnokii (#677750), requested 1174 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: 1332

   gridengine (#703256), requested 900 days ago
 Description: Distributed resource management
 Reverse Depends: gridengine-client gridengine-drmaa-dev
   gridengine-exec gridengine-master gridengine-qmon
 Installations reported by Popcon: 1154

   grub2 (#248397), requested 4133 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: debootstick grml-rescueboot grml2usb grub-coreboot
   grub-coreboot-bin grub-coreboot-dbg grub-disk grub-efi
   grub-efi-amd64 grub-efi-amd64-bin (38 more omitted)
 Installations reported by Po

Bug#797970: ITP: bangsh -- framework for easy shell scripting

[Paulo Kretcheu]

Package: wnpp
Severity: wishlist
Owner: Paulo Kretcheu 

* Package name: bangsh
  Version : 0.1.1
  Upstream Author : Gustavo.Dutra 
* URL : https://github.com/bangsh/bangsh
* License : MIT/X
  Programming Lang: Shell Script
  Description : framework for easy shell scripting

 This framework is intended to help on easy bash script development.
 It is totally modularized. It helps you developing new Bash Script
 programs by forcing you to modularize and organize your code in functions,
 so that your program can be tested.