Overriding/Masking system generators (Re: system upgrade by systemd)

[Michael Biebl]

Hi Dimitri

Am 01.09.2015 um 05:57 schrieb Dimitri John Ledkov:

> boot, whilst executing itself. And no upstream mechanisms are provided
> to disable particular generators.
> 

This is outdated/incorrect knowledge.
systemd generators nowadays support being overwritten just like normal
unit files. So masking a generator vi /etc/systemd/system-generators is
possible.

See man systemd.generator(7).

Regads,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: How to read mail addressed to "root" from "root" user?

[Wouter Verhelst]

(this isn't about Debian development anymore. I've added a Cc to
debian-user; if you have any follow-up questions, please drop the -devel
Cc).

On Mon, Aug 31, 2015 at 08:44:04PM +0300, Jayson Willson wrote:
> Thank you very much for your answer!
> Could you please tell me, why is it recommended to forward root's mail to
> regular user? I sometimes log in as root on tty or via sudo to administer
> system, and thus I would be able to have root's and user's mailboxes
> separated, while still reading root's mail.

Just have your system deliver it in a separate mailbox, then.

If you have the "allow_filter" option in your userforward router
enabled, you can do that by creating a file ~/.forward with the
following content:

# Exim filter <== do not remove this, exim checks it
if $h_to: contains "root"
then
  save /path/to/Maildir/rootmails/
  finish
endif

with the default exim config, this will cause it to be delivered in a
maildir with the given path name.

You can then read it with

mutt -f /path/to/Maildir/rootmails

as the normal user, rather than as root.

(or you could set up an IMAP server, yada yada)

> Is there anything that I have missed?

The security implications of using a MUA as root.

If there is an exploitable bug in your MUA, you may end up with a
compromised system.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller 

* Package name: s3backer
  Version : 1.4.1
  Upstream Author : Archie L. Cobbs 
* URL : https://www.github.com/archiecobbs/s3backer
* License : GPL, OpenSSL
  Programming Lang: C
  Description : Amazon AWS S3-backed virtual hard disk device

s3backer is a filesystem that contains a single file backed by the Amazon
Simple Storage Service (Amazon S3). The blocks of the file are stored as S3
objects. This way s3backer acts as a virtual hard disk device. s3backer also
offers encryption as part of the VHD.

s3backer offers some great benefits over s3fs as any filesystem can be used on
top of the VHD removing all inconsistencies which might occur with a naive
implementation of a filesystem.

Currently there is a license conflict between the GPL code and OpenSSL. I have
forwarded some of the common solutions to the upstream author.

Re: Security concerns with minified javascript code

[Marco d'Itri]

On Sep 01, Guido Günther  wrote:

> Couldn't we just use the non-minified versions in most situations? A
Not for anything which has actual users over the network.

> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer much from non minified JS.
doxygen-built documentation is often read online.

-- 
ciao,
Marco


pgptjBHX2z4Py.pgp
Description: PGP signature

Bug#797658: ITP: blends-images -- Pure Blends Live System Image Components

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: blends-images
  Version : 0.1
  Upstream Author : Debian Blends Team 
* URL : http://anonscm.debian.org/cgit/blends/blends-images.git/
* License : GPL-3+
  Programming Lang: live-build configurations
  Description : Pure Blends Live System Image Components

Hi,

This package contains the configuration directories for live-build to build
live system images for the Debian Pure Blends.

This package is modelled on the existing live-images package and
co-ordination has already taken place from the Debian UK BBQ to check that
this is a sensible way forward allowing automatic builds of testing images
on cdbuilder.debian.org.

Thanks,
Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: EPVPN 2105
c: 2M0STB  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpoTGzB7rdVp.pgp
Description: PGP signature

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦ 31 août 2015 11:21 -0400, Marvin Renich  :

>> > However, this is a readable source code that will accomodate any
>> > modification that a end user will deem necessary.
>
> I intentionally did not look at the file referred to above, and have no
> idea whether I would consider it to be a "preferred form" or not.  I
> merely wanted to debunk the "original author's preferred form is the
> only form that can be considered preferred" statement.

Well, I agree with you: there are too many use cases to only have one
preferred form. And this whole thread has a bunch of people who assume
that the unminified jquery.js file is the preferred form of
modification.

The easy actionable step that can be done is to just ensure that
packages are shipped with those pre-minification JS files (considered as
source files) and minify them with either yui-compressor or uglifyjs
that are present in main.
-- 
It usually takes more than three weeks to prepare a good impromptu speech.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#797675: ITP: python-pbalign -- maps Pacific Biosciences reads to reference sequences

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
Control: block 787977 by -1

* Package name: python-pbalign
  Version : 0.2.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbalign
* License : BSD
  Programming Lang: Python
  Description : maps Pacific Biosciences reads to reference DNA sequences

pbalign aligns PacBio reads to reference sequences, filters aligned reads 
according to user-specific filtering criteria, and converts the output to 
either the SAM format or PacBio Compare HDF5 (e.g., .cmp.h5) format.

This package is part of the SMRTAnalysis suite and is to be handled by the
Debian Med team.

Bug#797676: ITP: python-kineticstools -- detecting DNA modifications from single molecule, real-time sequencing data

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
Control: block 787977 by -1

* Package name: python-kineticstools
  Version : 0.5.1
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/kineticsTools
* License : BSD
  Programming Lang: Python
  Description : detecting DNA modifications from single molecule, real-time 
sequencing data

kineticsTool loads IPDs observed at each position in the genome, and compares
those IPDs to value expected for unmodified DNA, and outputs the result of
this statistical test. The expected IPD value for unmodified DNA can come
from either an in-silico control or an amplified control. The in silico control
is trained by PacBio and shipped with the package. It predicts predicts the
IPD using the local sequence context around the current position. An amplified
control dataset is generated by sequencing unmodified DNA with the same
sequence as the test sample. An amplified control sample is usually generated
by whole-genome amplification of the original sample.

This package is part of the SMRT Analysis suite and is to be handled by the
Debian Med team.

Re: Security concerns with minified javascript code

[Helmut Grohne]

On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> Couldn't we just use the non-minified versions in most situations? A
> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer much from non minified JS.

I fail to see what problem that would solve here. The minification
happens on Debian's buildds using tools from main. What would we gain by
not doing it?

The context of your answer is one of security updates. Why would we want
to do security updates for the JavaScript shipped with documentation? Do
you see an attack vector here?

Even assuming an attack vector, I think the easiest way here would be to
upload a fixed Doxygen and then binNMU/nochange-NMU all reverse
dependencies.

Really, pulling Doxygen in this discussion is a straw man nowadays.
Please pick better examples or arguments.

Helmut

Re: Security concerns with minified javascript code

[Nikolaus Rath]

On Sep 01 2015, m...@linux.it (Marco d'Itri) wrote:
> On Sep 01, Guido Günther  wrote:
>
>> Couldn't we just use the non-minified versions in most situations? A
>
> Not for anything which has actual users over the network.

Why? (Don't forget about gzip encoding).


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: Bug#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device

[Nikolaus Rath]

On Sep 01 2015, Lennart Weller  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Lennart Weller 
>
> * Package name: s3backer
>   Version : 1.4.1
>   Upstream Author : Archie L. Cobbs 
> * URL : https://www.github.com/archiecobbs/s3backer
> * License : GPL, OpenSSL
>   Programming Lang: C
>   Description : Amazon AWS S3-backed virtual hard disk device
>
> s3backer is a filesystem that contains a single file backed by the Amazon
> Simple Storage Service (Amazon S3). The blocks of the file are stored as S3
> objects. This way s3backer acts as a virtual hard disk device. s3backer also
> offers encryption as part of the VHD.
>
> s3backer offers some great benefits over s3fs as any filesystem can be used on
> top of the VHD removing all inconsistencies which might occur with a naive
> implementation of a filesystem.

Why compare it with something that has been unmaintained for years and is
not even in Debian? (Leaving alone the fact that there are at least 3
projects calling themselves s3fs, but AFAIK they're all in similar
states).

Contrasting it with something like S3QL would probably be more helpful
:-).


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: Security concerns with minified javascript code

[Nikolaus Rath]

On Sep 01 2015, Helmut Grohne  wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
>> Couldn't we just use the non-minified versions in most situations? A
>> heavily loaded wordpress site might not be good example but e.g. doxygen
>> documentation probably doesn't suffer much from non minified JS.
>
> I fail to see what problem that would solve here. The minification
> happens on Debian's buildds using tools from main. What would we gain by
> not doing it?

We would ensure that the shipped sources actually work. If you ship the
source, but the package is not using it (but the minified version that
was obtained by other means), experience has shown that the shipped
tends to get out-of-sync or otherwise useless.

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: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  1 septembre 2015 08:21 -0700, Nikolaus Rath  :

>>> Couldn't we just use the non-minified versions in most situations? A
>>
>> Not for anything which has actual users over the network.
>
> Why? (Don't forget about gzip encoding).

See:
 https://mathiasbynens.be/demo/jquery-size
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Security concerns with minified javascript code

[Marvin Renich]

> On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote:
> > * Bas Wijnen  [150830 07:53]:
> > > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> > > > Is that the preferred form of modification? It depends, but from the
> > > > jQuery author point of view, it isn't:
> > > 
> > > Then it isn't.
> > 
> > I take exception to this.
> 
> I agree with your point.  What I meant to say is that what upstream actually
> uses for modifying the work is what we should use as source.  That may change
> if upstream changes, and it may not be a clear definition anyway if upstream
> consists of multiple people and they have different ideas about it.  But most
> of the time this is very clear; if you send a patch and they say "that's not
> the file I use for editing", then it's not the source.

Okay, in general what upstream uses (if it satisfies Debian's definition
of source) is what we should try to use if we don't have a reason to do
otherwise, but not doing so does not violate the DFSG.  That is not the
purpose of the DFSG requiring source.  The purpose is so that
downstreams can fork, using their own repositories and distribution
mechanisms, and perhaps different mandatory coding styles for acceptance
into their repos.  And then a downstream of a first-level downstream can
do the same.

Perhaps one downstream likes to refactor to decrease the total number of
files, and another likes to decrease the average number of lines per
file.  Both are still valid DFSG-compliant source.

> > Also note that the phrase "preferred form of the work for making
> > modifications to it" comes from the GPL, not from the DFSG.
> 
> True, but we don't have a definition ourselves, and there seems to be 
> consensus
> that this is a good one.

Agreed.

...Marvin

Bug#797692: ITP: aiocoap -- Python implementation of CoAP

[Agustin Henze]

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


   Package name: aiocoap
Version: 0.1
Upstream Author: Maciej Wasilak , Christian
Amsüss 
URL: https://github.com/chrysn/aiocoap
License: MIT/X11
Description: Python implementation of CoAP
 The aiocoap package is a Python implementation of CoAP, the Constrained
 Application Protocol (RFC 7252, more info at http://coap.technology/).
 .
 It uses the asyncio module introduced in Python 3.4 to facilitate concurrent
 operations while maintaining a simple to use interface and not depending on
 anything outside the standard library.

-- 
TiN

Re: Security concerns with minified javascript code

[Nikolaus Rath]

On Sep 01 2015, Vincent Bernat  wrote:
>  ❦  1 septembre 2015 08:21 -0700, Nikolaus Rath  :
>
 Couldn't we just use the non-minified versions in most situations? A
>>>
>>> Not for anything which has actual users over the network.
>>
>> Why? (Don't forget about gzip encoding).
>
> See:
>  https://mathiasbynens.be/demo/jquery-size

I don't think 28 kB vs 73 kB is a difference that people will notice
over the network in *most* situations. Even at just 100 kB/s that's
0.28 vs 0.73 seconds, and only when the page is first loaded.


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


signature.asc
Description: PGP signature

Re: Security concerns with minified javascript code

[Raphael Hertzog]

Hi,

On Mon, 31 Aug 2015, Bas Wijnen wrote:
> > I certainly do not want to move wordpress or publican to contrib because
> > some of the javascript libraries that it uses can't be rebuilt from main.
> 
> In that case, my question applies to you as well: why do you care for it to be
> in main, if you are unwilling to follow the rules we have set up for it?
>
> > Do you see now how you question is not constructive? The javascript bits
> > are free software
> 
> Which require a compiler that is not in main to build.  That is the definition
> of what contrib is for.  Why shouldn't it go in there?

Because we have alternative "compilers" (aka minifier) available to
recreate another minified file thas should work just as well.

For me, the javascripts bits in wordpress/publican are not part of the
product, they are external libraries whose preferred form of use is
by embedding a copy of the library... that sucks but it's the way it is.

I do not see significant value in extending my packaging to rebuild
the minified files from source as part of the wordpress/publican source
package. On the opposite, it has a significant cost:
- I have to add the sources when upstream does not ship them
  (which is not a problem for many upstreams since the BSD-ish
  licences do not require you to provide the sources)
- ensure the sources are in sync with the minified copy
  (even when friendly upsreams provide the required sources
  on our request, they sometimes updates only one the minified file
  and forget about the sources in some other directory)
- if the minifier is not the same as upstream, it will create
  a divergence with upstream and can always be a source of
  suspicion when we report issues to upstream...

In the end, if the end-user wants to make some changes to the javascript
libraries embedded in wordpress/publican, they can grab the source package
of the corresponding libraries, do their changes and build modified
libraries there. After that they can update it in the publican/wordpress
package by replacing the embedded copy.

> Are you arguing that having tools to go from source to binary available in 
> main
> should not be a requirement for a package to be in main?

No.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Security concerns with minified javascript code

[Marvin Renich]

* Raphael Hertzog  [150901 12:57]:
> Because we have alternative "compilers" (aka minifier) available to
> recreate another minified file thas should work just as well.

No.  Debian does not allow you to ship a compiled C program that was
compiled elsewhere; the maintainer or a buildd is responsible for taking
the source and creating an executable.  The same applies to minified JS.
I don't see how anyone can argue that minified JS is different.

(And besides, "different but works just as well" is not even close to
the same as "could be built from source, but just wasn't".)

Sometimes doing the right thing is hard.  The GFDL issue is an example;
it took a large effort and a lot of time, but we finally did it.  We did
not remove all GFDL source in one shot.  We decided it really was a
problem, started filing bugs, and started fixing them.  I believe there
was a release in the middle of the purge that ignored (for RC purposes)
those bugs, but we did eventually get all GFDL-licenced material moved
to non-free.

We should do the same for minified JS that is not built using tools in
main.

...Marvin

Re: Polkit: prompt for root password

[Jayson Willson]

I have also tried creating 
/usr/share/polkit-1/rules.d/49-rootpw_global.rules with the same 
contents, as it seems like some other rules reside there. Still no result


Yours sincerely, Jayson Willson

31.08.2015 13:49, Jayson Willson пишет:

Hello everybody!
I would like Polkit to prompt for _root_ password, not _user_ password.
On archwiki I found the following advice: create
/etc/polkit-1/rules.d/49-nopasswd_global.rules

and put the following into it:

/etc/polkit-1/rules.d/49-rootpw_global.rules

/* Always authenticate Admins by prompting for the root
  * password, similar to the rootpw option in sudo
  */
polkit.addAdminRule(function(action, subject) {
 return ["unix-user:root"];
});


However, it doesn't work on my Debian Stable system even after I reboot
the system. Polkit still prompts for user password. What should I do?

Re: Security concerns with minified javascript code

[Marco d'Itri]

On Sep 01, Nikolaus Rath  wrote:

> I don't think 28 kB vs 73 kB is a difference that people will notice
> over the network in *most* situations. Even at just 100 kB/s that's
> 0.28 vs 0.73 seconds, and only when the page is first loaded.
Yes, this is a non trivial difference when loading a web page.
Any tutorial on modern web development would teach this.

-- 
ciao,
Marco


pgpvZb01Jz9YH.pgp
Description: PGP signature

Bug#797701: ITP: grafana-zabbix -- Zabbix datasource for Grafana dashboard

[Dmitry Smirnov]

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

Package name: grafana-zabbix
 Version: 2.0.1
Upstream Author : Alexander Zobnin 
 License: Apache-2.0
Programming Lang: JavaScript
 URL: https://github.com/alexanderzobnin/grafana-zabbix
 Description: Zabbix datasource for Grafana dashboard
 Grafana datasource plugin to display Zabbix data directly in Grafana
 dashboards.


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

Bug#797702: ITP: grafana -- feature rich metrics dashboard and graph editor

[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: grafana
 Version: 2.1.3
 License: Apache-2.0
Programming Lang: Go, JavaScript
 URL: http://grafana.org
 Description: feature rich metrics dashboard and graph editor
 Grafana is a feature rich metrics dashboard and graph editor for Graphite,
 InfluxDB & OpenTSDB.


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

Re: Polkit: prompt for root password

[Matthias Klumpp]

2015-09-01 19:49 GMT+02:00 Jayson Willson :

> I have also tried creating
> /usr/share/polkit-1/rules.d/49-rootpw_global.rules with the same contents,
> [...]


The problem with that is simply that the PolicyKit in Debian
Unstable/Testing/Stable does not read the JavaScript rules files.
Only the version using JS-based rules files (in experimental for ages) does
that. So you might want to search for a solution using the old
configuration syntax here.
Cheers,
Matthias

Re: system upgrade by systemd

[Gunnar Wolf]

Raphael Hertzog dijo [Wed, Aug 26, 2015 at 02:41:59PM +0200]:
> > Please tell me which package is the one misbehaving and I gladly report it.
> > But so far I have yet to figure that our.
> 
> Are you sure that you did not shutdown your computer from GNOME and did
> not pay attention to the new checkbox allowing it to install upgrades
> during shutdown/boot?
> 
> I have seen it once already and I have always unchecked it.

Ough.

I thought that checkbox was part of the Windows 7 shutdown logic, not
of GNOME :-/

Bug#797704: ITP: pyhton-rows -- Python library for interface to tabular data, no matter the format

[Paulo Kretcheu]

Package: wnpp
Severity: wishlist
Owner: Paulo Roberto Alves de Oliveira (aka kretcheu) 

* Package name: pyhton-rows
  Version : 0.1.0
  Upstream Author : Álvaro Justen 
* URL : https://github.com/turicas/rows
* License : GPL-3
  Programming Lang: Python
  Description : Python library for interface to tabular data, no matter the 
format

No matter in which format your tabular data is: pyhton-rows will import it,
automatically detect types and give you high-level Python objects so you can
start working with the data instead of trying to parse it.
It is also locale-and-unicode aware.

The library is composed by:

- A common interface to tabular data (the Table class)
- A set of plugins to populate Table objects CSV, XLS, HTML, TXT -- more soon!
- A set of common fields (such as BoolField, IntegerField) which know exactly
  how to serialize and deserialize data for each object type you'll get
- A set of utilities (such as field type recognition) to help working with
  tabular data
- A command-line interface so you can have easy access to the most used 
features:
  convert between formats, sum, join and sort tables.
  Just import rows and relax.

Re: Security concerns with minified javascript code

[Guido Günther]

On Tue, Sep 01, 2015 at 04:42:15PM +0200, Helmut Grohne wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> > Couldn't we just use the non-minified versions in most situations? A
> > heavily loaded wordpress site might not be good example but e.g. doxygen
> > documentation probably doesn't suffer much from non minified JS.
> 
> I fail to see what problem that would solve here. The minification
> happens on Debian's buildds using tools from main. What would we gain by
> not doing it?

Iff we have the tools in main to minify there's of course no reason to
ship unminified JS. One can just minify during the build.

> The context of your answer is one of security updates. Why would we want
> to do security updates for the JavaScript shipped with documentation? Do
> you see an attack vector here?
> 
> Even assuming an attack vector, I think the easiest way here would be to
> upload a fixed Doxygen and then binNMU/nochange-NMU all reverse
> dependencies.
> 
> Really, pulling Doxygen in this discussion is a straw man nowadays.
> Please pick better examples or arguments.

There are others. Mozilla extensions, groupware suites, etc. In many
situations going for the unminified version just solves the security
issue without any damage.

Cheers,
 -- Guido

Re: Polkit: prompt for root password

[Jayson Willson]

Thank you for your advice, I have found the way:
Comment out file 
/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf, which overrides 
/etc/polkit-1/localauthority.conf.d/50-localauthority.conf and makes 
polkit consider members of "sudo" groups as administrators.


Yours sincerely, Jayson Willson

01.09.2015 21:16, Matthias Klumpp пишет:

2015-09-01 19:49 GMT+02:00 Jayson Willson mailto:jaysonwillson...@gmail.com>>:

I have also tried creating
/usr/share/polkit-1/rules.d/49-rootpw_global.rules with the same
contents, [...]


The problem with that is simply that the PolicyKit in Debian
Unstable/Testing/Stable does not read the JavaScript rules files.
Only the version using JS-based rules files (in experimental for ages)
does that. So you might want to search for a solution using the old
configuration syntax here.
Cheers,
 Matthias

Re: Polkit: prompt for root password

[Michael Biebl]

Am 01.09.2015 um 20:29 schrieb Jayson Willson:
> Thank you for your advice, I have found the way:
> Comment out file
> /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf, which overrides
> /etc/polkit-1/localauthority.conf.d/50-localauthority.conf and makes
> polkit consider members of "sudo" groups as administrators.

So you user was in group "sudo", having admin privileges.
Just curious: why do you then want to prompt for the root password and
not the user password for that user?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Vincent Bernat dijo [Fri, Aug 28, 2015 at 11:54:43AM +0200]:
> > I still find it hard to believe that *so* much code is required to
> > minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> > would appear to be that nobody actually *cares* about the mess, they
> > just use it.
> 
> It's a feature. The JS community is quite proud to have so many packages
> for so little tiny tasks. Their packaging system enables to do this
> "easily".

Sounds much like the canonical description of Unix, only throwing
aside tens of years of engineering best practices.

> > Why isn't there a KISS tool to do this? Is it all just special
> > snowflake optimisations for what has to be / should be a simple process
> > of removing whitespace and collapsing the formatting?
> 
> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not
> require only minification. They require transpiling (convert from ES6 to
> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency
> handling (through loaders). And this is becoming more and more common
> because people want to use ES6 or some more modern JS.

...If so, they should be properly labeled and treated as something
different. "Transpiling" effectively means "compiling", and we know
what requirements we have with code in order to accept it compiled: We
need to have the sources as well. Nobody will argue that we don't have
to ship sources for binaries on ARM platforms because ARM has enough
registers so that compiled objects are as good as source.

And, of course, having a tool behave as a compiler when it does not
really understand the mess it is creating... Well, leads to gaping
holes such as what Yan describes here:

https://zyan.scripts.mit.edu/blog/backdooring-js/

A beautiful way of showing how minification hurts.

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Vincent Bernat dijo [Fri, Aug 28, 2015 at 10:48:28AM +0200]:
> >> What will happen is that maintainers will fallback to the second less
> >> horrible solution and cripple the package (by using an older version of
> >> the JS lib for example) to allow it to stay in main.
> >
> > Why would they want to stay in main?
> 
> [...]
> 
> > I had the same issue with loadlin: it could only be built on MS-DOS with
> > the proprietary tasm, and thus got #356055. I thus extended the free
> > yasm to recognized the tasm syntax, and patched loadlin a bit to remove
> > some extensions which were hard to implement in yasm but easy to replace
> > in loadlin.
> >
> > Then it could stay in main.
> 
> Here is why.

So, in short, this could be read as "it implies extra work".

But what makes Debian famous for is that we as developers *do* make
that extra work.

It is a great benefit to our users, and it's a core value of the
project. So core, that it is encoded in our foundational documents. 

Re: Polkit: prompt for root password

[Jayson Willson]

It seems to me, that such approach will increase security. If "sudo" and 
"policykit" prompt for user password, then even if some other man knows 
my user password, he can administer system, as he can both log into the 
system and user sudo/polkit, but if root password is required for using 
sudo/polkit, then knowing my user's password is not enough, and the only 
thing he will be able to change is files in /home/user.


Yours sincerely, Jayson Willson

01.09.2015 21:45, Michael Biebl пишет:

Am 01.09.2015 um 20:29 schrieb Jayson Willson:

Thank you for your advice, I have found the way:
Comment out file
/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf, which overrides
/etc/polkit-1/localauthority.conf.d/50-localauthority.conf and makes
polkit consider members of "sudo" groups as administrators.


So you user was in group "sudo", having admin privileges.
Just curious: why do you then want to prompt for the root password and
not the user password for that user?

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  1 septembre 2015 13:45 -0500, Gunnar Wolf  :

>> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not
>> require only minification. They require transpiling (convert from ES6 to
>> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency
>> handling (through loaders). And this is becoming more and more common
>> because people want to use ES6 or some more modern JS.
>
> ...If so, they should be properly labeled and treated as something
> different. "Transpiling" effectively means "compiling", and we know
> what requirements we have with code in order to accept it compiled: We
> need to have the sources as well. Nobody will argue that we don't have
> to ship sources for binaries on ARM platforms because ARM has enough
> registers so that compiled objects are as good as source.

The term transpiling is used because it is mostly a matter of tweaking a
bit the syntax (ES6 has an arrow function syntax not present in ES5) and
inserting polyfills. See for example the future version of jQuery
written with ES6 but transpiled to ES5:

 https://code.jquery.com/jquery-git.js

Unlike ARM binary, this is still Javascript, the indentation and the
comments are still here. The variables have the exact same name. Most
people wouldn't have any problem of believing that this is the base
source code of jQuery because it looks like how jQuery would have been
written in ES5 JS (like it is with jQuery 1.x and 2.x).
-- 
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the
Rings"]


signature.asc
Description: PGP signature

Re: Polkit: prompt for root password

[Michael Biebl]

Am 01.09.2015 um 20:54 schrieb Jayson Willson:
> It seems to me, that such approach will increase security. If "sudo" and
> "policykit" prompt for user password, then even if some other man knows
> my user password, he can administer system, as he can both log into the
> system and user sudo/polkit, but if root password is required for using
> sudo/polkit, then knowing my user's password is not enough, and the only
> thing he will be able to change is files in /home/user.

Why did you then put your user in group sudo in the first place if what
you want is "su" type behaviour?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Security concerns with minified javascript code

[Didier 'OdyX' Raboud]

Le mardi, 1 septembre 2015, 17.50:26 Vincent Bernat a écrit :
>  ❦  1 septembre 2015 08:21 -0700, Nikolaus Rath  :
> >>> Couldn't we just use the non-minified versions in most situations?
> >>> A
> >> 
> >> Not for anything which has actual users over the network.
> > 
> > Why? (Don't forget about gzip encoding).
> 
> See:
>  https://mathiasbynens.be/demo/jquery-size

What this tells us is that the size wins for the latest jquery version 
are the following :

* gzip only -> 29.7%
* zopfli only -> 28.1%
* minifying + gzip -> 11.9%
* minfying + zopfli -> 11.5%

So, taking this jquery example, if minifying is too hard, we can still 
go below 30% of the total size by applying gzip only.

That said…

We should not forget that "minified+gzipped JS" is only a temporary 
state of things. The web ecosystem moved from "ship the full JS source 
to users" (which was way easier in terms of software freedom) to 
"miinified JS". We're at the point where we debate whether this 
"minified JS" is valid source for us (technically, it is valid JS code, 
but not the preferred form of modification).

But the web ecosystem is moving towards WebAssembly [0,1], that will be 
"a portable, size- and load-time-efficient binary format" [2]. Where 
"minified JS" could be seen as source-code, WebAssembly will definitely 
not. If we accept the compromise to not run the compilation step from JS 
to "minified JS", will it be tenable to not run it either for 
_binaries_?

Although I'm concerned by this, I don't doubt much that WebAssembly (or 
any other binary format for the web) _will_ be coming to the web, our 
upstreams, and will become their preferred way to ship frontend code to 
their users. We'll have to deal with that, and we should get ourselves 
ready for that.

The current web compilation stack is arguably ugly, painful to maintain, 
and a big source of frustration, and I can therefore understand how 
maintainers end up not doing the compilation in the Debian package 
build; but really, if we don't do it now, what will happen with binary 
formats?

I think we should take a strong move there and exercise (as well as 
justify to the outer world) our free software right to recompile the 
software that we ship to our users: this could mean to only merge & gzip 
JS files if minifying isn't realistic [3]. Not doing so _is_ going to 
hurt our ability to exercise our freedoms in the future, it's also 
making a disservice to our users.

Cheers,
OdyX

[0] https://blog.mozilla.org/luke/2015/06/17/webassembly/
[1] https://github.com/WebAssembly
[2] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md
[3] Reducing to 29% instead of 12% might be the price of our freedom
there…

Re: Polkit: prompt for root password

[Jayson Willson]

Ehmm... I do not know. Probably, what I have done is not correct. As I 
understand, if my user is NOT in sudo group, then su prompts for root 
password (just as always), and polkit will also prompt for root 
password, instead of my user's.
However, sudo seems to be more flexible, and though I do not need all of 
it's flexibility now, I may need it later.

All the changes, which I had to make is:
add
"Defaults  rootpw"
to /etc/sudoers
and do polkit rules changes mentioned above. Are there any reasons _not_ 
to change config files and switch to su without sudo instead?


Yours sincerely, Jayson Willson

01.09.2015 22:02, Michael Biebl пишет:

Am 01.09.2015 um 20:54 schrieb Jayson Willson:

It seems to me, that such approach will increase security. If "sudo" and
"policykit" prompt for user password, then even if some other man knows
my user password, he can administer system, as he can both log into the
system and user sudo/polkit, but if root password is required for using
sudo/polkit, then knowing my user's password is not enough, and the only
thing he will be able to change is files in /home/user.


Why did you then put your user in group sudo in the first place if what
you want is "su" type behaviour?

Re: Polkit: prompt for root password

[Michael Biebl]

Am 01.09.2015 um 21:13 schrieb Jayson Willson:
> Ehmm... I do not know. Probably, what I have done is not correct. As I
> understand, if my user is NOT in sudo group, then su prompts for root
> password (just as always), and polkit will also prompt for root
> password, instead of my user's.

Correct.

> However, sudo seems to be more flexible, and though I do not need all of
> it's flexibility now, I may need it later.
> All the changes, which I had to make is:
> add
> "Defaultsrootpw"
> to /etc/sudoers
> and do polkit rules changes mentioned above. Are there any reasons _not_
> to change config files and switch to su without sudo instead?

Just to clarify: I'm one of the policykit maintainers and we modelled
the default policy in Debian this way, that you'll be prompted for your
user password if you are in group sudo, since that is what we'd expect
admins to happen if they put users in group sudo, to grant them admin
privileges.

So I was interested why you wanted to work it differently.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦  1 septembre 2015 21:10 +0200, Didier 'OdyX' Raboud  :

> I think we should take a strong move there and exercise (as well as 
> justify to the outer world) our free software right to recompile the 
> software that we ship to our users: this could mean to only merge & gzip 
> JS files if minifying isn't realistic [3]. Not doing so _is_ going to 
> hurt our ability to exercise our freedoms in the future, it's also 
> making a disservice to our users.

It seems this thread shed too much tears and is too much focused on
minification. The minification step is usually easy. We have
yui-compressor (that nobody uses upstream, hence the small risk of using
it) and uglifyjs (but a version vulnerable to the attack at the origin
of this thread). What's difficult is to get the code to be modified from
the original source. There are two difficulties:

 1. Upstream may not ship this source but only the minified version
because the JS code is just a dependency and some upstream are used
to just ship the minified source. We can recover the original code
from another source but there is a risk that this is not really the
original code because many JS projects have a modular build (jQuery,
modernizr, ...). This is what Raphael is explaining for Wordpress (I
think).

 2. Upstream may generate the final pre-minification file with complex
tools, like an AMD loader or an ES6/ES5 transpiler, along with the
use of non-packaged build tools like Grunt.

Unfortunately, I don't have an immediate solution for the first
problem. For the second one, a solution would be to consider the
pre-minification JS code to be perfectly valid source code
(indentations, comments, variable names, everything is here).
-- 
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Security concerns with minified javascript code

[Don Armstrong]

On Tue, 01 Sep 2015, Vincent Bernat wrote:
>  1. Upstream may not ship this source but only the minified version
>  because the JS code is just a dependency and some upstream are used
>  to just ship the minified source. We can recover the original code
>  from another source but there is a risk that this is not really the
>  original code because many JS projects have a modular build (jQuery,
>  modernizr, ...). This is what Raphael is explaining for Wordpress (I
>  think).

This is precisely why the actual source code is required. This is no
different than a C program shipping a .a file. Perhaps one from a
specific version of a library from which we may have the source code but
which may or may not have been modified in some way which is absolutely
essential for the functioning of the code, but not noted anywhere.

It sucks that this is difficult, but freedom zero is really important,
and requires source code. I mean, we're still working with upstreams who
write C code, and that's been non-controversial for decades.

-- 
Don Armstrong  http://www.donarmstrong.com

As nightfall does not come at once, neither does oppression. In both
instances, there is a twilight when everything remains seemingly
unchanged. And it is in such twilight that we all must be most aware
of change in the air -- however slight -- lest we become unwitting
victims of the darkness.
 -- William O. Douglas

Bug#797713: ITP: python-stetl -- Streaming ETL - geospatial ETL framework for Python

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: python-stetl
  Version : 1.0.8
  Upstream Author : Just van den Broecke 
* URL : http://stetl.org/
* License : GPL-3+
  Programming Lang: Python
  Description : Streaming ETL - geospatial ETL framework for Python 2

Stetl, streaming ETL, pronounced "staedl", is a lightweight ETL-framework
for the conversion of rich (as GML) geospatial data conversion.

It basically glues together existing parsing and transformation tools
like GDAL/OGR (ogr2ogr) and XSLT. By using native tools like libxml and
libxslt (via Python lxml) Stetl is speed-optimized.

Stetl has a similar design as Spring (Java) and other modern frameworks
based on IoC (Inversion of Control). A configuration file (in Python
config format) specifies your chain of ETL steps. This chain is formed
by a series of Python modules/objects and their parameters. These are
symbolically specified in the config file. You just invoke etl.py the
main program with a config file. The config file specifies the input
modules (e.g. PostGIS), transformers (e.g. XSLT) and outputs (e.g. a GML
file or even WFS-T a geospatial protocol to publish GML to a server).


Stetl is required for the TOP10NL ETL port of NLExtract, and the package
will be maintained within the Debian GIS team.

Bug#797720: ITP: python-ly -- Tool and Python library for manipulating LilyPond files

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: python-ly
  Version : 0.9.2
  Upstream Author : Wilbert Berendsen 
* URL : https://pypi.python.org/pypi/python-ly
* License : GPL-2+
  Programming Lang: Python
  Description : Tool and Python library for manipulating LilyPond files

 This package provides a Python library `ly` containing various Python
 modules to parse, manipulate or create documents in LilyPond format.
 A command line program `ly` is also provided that can be used to do various
 manipulations with LilyPond files.
 .
 The LilyPond format is a plain text input format that is used by the
 GNU music typesetter LilyPond (www.lilypond.org).


 1. Why is this package useful/relevant?  Is it a dependency for
another package?

Answer: python-ly is needed for the Qt4-based LilyPond sheet music editor
Frescobaldi 2.18 and above, which I intend to upload after python-ly
is accepted.  Debian currently has frescobaldi-2.17.2 where the
functionality of python-ly was not yet separated out.

 2. How do you plan to maintain it?  Inside a packaging team?

Yes, I intend to join the Debian Python Modules Team (DPMT)
to have the python-ly source package reside on Alioth.
Frescobaldi, which I co-maintain, is already inside the
Python Applications Packaging Team (PAPT).

Re: Security concerns with minified javascript code

[Josh Triplett]

Nikolaus Rath wrote:
> I don't think 28 kB vs 73 kB is a difference that people will notice
> over the network in *most* situations. Even at just 100 kB/s that's
> 0.28 vs 0.73 seconds, and only when the page is first loaded.

That's absolutely a critical difference, even on a faster connection.
Multiple studies have demonstrated that page load time matters for user
retention.  Amazon did a study that showed every ~100ms of page load
delay lost them 1% in sales.  Google found that half a second slower
load time for results pages drove off 20% of users.  Google also
prioritizes faster sites in search results.

So yes, minifiers matter.  (Hopefully WebAssembly will help in the
future, since even minified JavaScript runs through a text-based
lexing/parsing engine; compiled code could almost certainly beat it on
size.)

That said, we absolutely do need to fix this in Debian: it's not OK to
build packages in main using tools not shipped in Debian, or to ship
precompiled files.  As a start, it would help if when JavaScript folks
try to package the packages needed as part of their toolchain, they stop
getting told that their packages are too small, that they shouldn't be
packaged at all, or that they should be combined with other packages
that have different upstream sources and release cycles.

- Josh Triplett

Re: Security concerns with minified javascript code

[Russ Allbery]

Josh Triplett  writes:

> That said, we absolutely do need to fix this in Debian: it's not OK to
> build packages in main using tools not shipped in Debian, or to ship
> precompiled files.  As a start, it would help if when JavaScript folks
> try to package the packages needed as part of their toolchain, they stop
> getting told that their packages are too small, that they shouldn't be
> packaged at all, or that they should be combined with other packages
> that have different upstream sources and release cycles.

I want to highlight this, because it's an important point that I don't
think had previously been raised in this thread.  There are some
communities that make a practice of releasing very small units of code.  I
understand that our current metadata management and distribution framework
makes this less than ideal for the archive, but I think it would be
worthwhile investing some effort into fixing that instead of pushing
packagers to either not package those components or do a lot more work to
try to create rollup packages that aren't what anyone expects.

Healthy language communities have their own metadata systems and
standardized build systems that allow Debian packaging to be nearly
automated, *provided* that we use the same unit of distribution as
upstream.  If we want to make any headway on the huge Javascript
ecosystem, we can't rely on individuals hand-packaging each one of those
libraries.  We need to be able to use tools to do nearly all the packaging
work automatically and ask humans only to do sanity checking and bug
triage and the other parts of the work that we can't automate.  And that's
way harder if they also have to fight with rebundling upstream releases
into some other format.

I'm not sure how much practical impact this has had, but I know it's come
up a few times, just as it's come up occasionally with Perl modules and
other packages.  If the metadata issues with introducing another ~100
packages in order to model an upstream distribution properly are serious,
that would be a great thing that people in Debian could work on fixing, to
make it much more likely that we can properly package these tools.

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

Re: Security concerns with minified javascript code

[Nikolaus Rath]

On Sep 01 2015, Josh Triplett  wrote:
> Nikolaus Rath wrote:
>> I don't think 28 kB vs 73 kB is a difference that people will notice
>> over the network in *most* situations. Even at just 100 kB/s that's
>> 0.28 vs 0.73 seconds, and only when the page is first loaded.
>
> That's absolutely a critical difference, even on a faster connection.
> Multiple studies have demonstrated that page load time matters for user
> retention.  Amazon did a study that showed every ~100ms of page load
> delay lost them 1% in sales.  Google found that half a second slower
> load time for results pages drove off 20% of users.  Google also
> prioritizes faster sites in search results.

Yes, but neither Amazon nor Google (nor any other Web application for
which this matters) is likely to run javascript from a vanilla Debian
package. This is not about minification in general, but about
minification in Debian packages. I don't care enough to actually make a
statistic, but I would not be surprised if most of the javascript that's
carried in Debian ends up in /usr/share/doc.

(end of thread for me)

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: Security concerns with minified javascript code

[Lars Wirzenius]

On Tue, Sep 01, 2015 at 06:05:09PM -0700, Russ Allbery wrote:
> Healthy language communities have their own metadata systems and
> standardized build systems that allow Debian packaging to be nearly
> automated, *provided* that we use the same unit of distribution as
> upstream.  If we want to make any headway on the huge Javascript
> ecosystem, we can't rely on individuals hand-packaging each one of those
> libraries.  We need to be able to use tools to do nearly all the packaging
> work automatically and ask humans only to do sanity checking and bug
> triage and the other parts of the work that we can't automate.  And that's
> way harder if they also have to fight with rebundling upstream releases
> into some other format.

I fully agree with this. Thank you, Russ, for expressing it clearly.

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.
That's going to be a lot of packages, and that alone makes things
harder to manage for everyone. It'd make sense for the Javascript
community to produce a more general library to make ES5 look more like
ES6, which would include a number of such functions.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh

Re: Bug#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device

[Lennart Weller]

September 1 2015 5:27 PM, "Nikolaus Rath"  wrote:
> Why compare it with something that has been unmaintained for years and is
> not even in Debian? (Leaving alone the fact that there are at least 3
> projects calling themselves s3fs, but AFAIK they're all in similar
> states).
> 
> Contrasting it with something like S3QL would probably be more helpful
> :-).

As you said there are three different projects with the name s3fs. But the one 
I was
referring to, s3fs-fuse[1], is actively maintained while s3fs (python)[2] and 
s3fslite[3] are not.
The name doesn't really matter though as the approach of all of them and S3QL 
is pretty much the same.
Create an S3 based filesystem.

s3backer on the other hand exposes just a single "block" device to the system 
and allows common filesystems
to be used on top of it. I kinda like that approach so I went with it.

Cheers,
Lennart Weller


[1] https://github.com/s3fs-fuse/s3fs-fuse
[2] https://fedorahosted.org/s3fs/
[3] https://github.com/russross/s3fslite