Re: copyright precision

[Johannes Schauer]

Hi,

Quoting Paul Wise (2016-08-10 05:12:55)
> The only possible way to solve this in general terms is, accurate document
> the copyright/license of the source package using the machine-readable format
> and during builds, track the transformation of input files in the source
> package to output files in the binary package and then generate the
> copyright/license information for the binary package based on which input
> files from which source/binary packages ended up in the new binary package.

in the past I investigated this problem myself as well. I came to the
conclusion that with the current available techniques it is impossible to
reliable trace process execution and system calls in all scenarios (i.e. for
all source package) and without a way to reliably (and automatically) figure
out for which source packages it does work. Thus I gave up and asked this
question:

http://unix.stackexchange.com/questions/188849/how-to-reliably-and-transparently-trace-process-execution

Helmut also once wrote a proof of concept that tackled the problem of
generating linearized build logs but also ran into the problem that his
approach failed if events happened too fast.

Using ptrace we could today write a program that analyzes our builds (on Linux)
and generates the required information to extract copyright information and a
bunch of more useful and interesting data. Unfortunately this would not work
for all source packages in the archive as a ptraced process cannot execute
ptrace themselves. Maybe this problem could be alleviated by running source
package builds with nocheck as I would expect ptrace being mainly used in test
cases and not during the real build. Reproducible builds could also be used to
make sure that a ptraced build produced the same binary packages as a
non-ptraced build.

Unfortunately, because of the involved limitations, I gave up on the project.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Key collisions in the wild

[Jakub Wilk]

https://codesearch.debian.net/search?q=%5Cbgpg2%3F%5Cb.*--recv%28-keys%3F%29%3F%5Cs%2B%280x%29%3F%5B0-9a-fA-F%5D%7B8%7D%5Cb

(And there's probably more that this simplistic search doesn't catch...)

Any volunteers to file bugs?

--
Jakub Wilk

Re: Key collisions in the wild

[Jakub Wilk]

* Samuel Thibault , 2016-08-10, 01:17:

Samuel Thibault, on Wed 10 Aug 2016 00:47:43 +0200, wrote:

€ gpg --search-key samuel.thiba...@gnu.org
...
(1) Samuel Thibault 
4096 bit RSA key 7D069EE6, created: 2014-06-16


And it has 55 signatures from 55 colliding keys...


The forger botched it up, because all its signatures have almost the 
same creation time. You can tell it's a sham key from quite a long way 
away.


--
Jakub Wilk

use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Holger Levsen]

Hi Samuel,

On Wed, Aug 10, 2016 at 12:47:43AM +0200, Samuel Thibault wrote:
> As a late follow-up of the gpg key collision thread from debian-private
> (but posted on debian-devel, there is nothing private here, I prefer to
> see this information publicized actually):
> 
> € gpg --search-key samuel.thiba...@gnu.org
> ...
> (1) Samuel Thibault 
> 4096 bit RSA key 7D069EE6, created: 2014-06-16
> (2) Samuel Thibault 
> 4096 bit RSA key 7D069EE6, created: 2010-09-14
> 
> So somebody *does* try to fake my gpg key too...
> 
> For the reminder,
> https://gwolf.org/node/4070

I'm somewhat surprised by this mail… or rather by you appearantly
knowing about the issue but still you seem to not have acted as advised,
so let me repeat: everybody, please put "keyid-format long" into your
~/.gnupg/gpg.conf!

then, the output will look like this:

$ grep keyid-format .gnupg/gpg.conf 
keyid-format long
$ gpg --search-key samuel.thiba...@gnu.org
...
(1) Samuel Thibault 
  4096 bit RSA key E2992EA47D069EE6, created: 2014-06-16
(2) Samuel Thibault 
Samuel Thibault 
Samuel Thibault 
Samuel Thibault 
Samuel Thibault 
  4096 bit RSA key D0178C767D069EE6, created: 2010-09-14


voila.


-- 
cheers,
Holger, puzzled to still see people using short-ids,
especially people who seem to be aware of the problem…


signature.asc
Description: Digital signature

Re: copyright precision

[Ian Jackson]

Helmut Grohne writes ("Re: copyright precision"):
> On Tue, Aug 09, 2016 at 07:45:16PM +0200, Thorsten Alteholz wrote:
> > So if there is a problem, shouldn't we start to solve it instead of just
> > ignoring it? Wouldn't it be better to set high standards instead of being
> > guided by convenience?
> 
> Documenting problems only makes sense when there is a realistic chance
> to get them fixed. If we end up letting them linger, the effort of
> reporting them is wasted.

Indeed.

> I'm not meaning to imply that we shouldn't fix this. I'm just seeing
> that few people are interested in actually doing what needs doing.

It seems like a lot of work.  And indeed, speaking personally:

I would fix any such bug in any package I had responsibility for, and
I might indeed fix any such bug in a package I wanted to do some
nontrivial work on.

But I have no desire to do the necessary legwork to go through the
whole archive to fix this kind of thing.

> Instead of seeing higher standards being applied, I'd like to see better
> tools that support meeting those standards. If generating augmented
> copyright files for binary packages is the way to go, there should be a
> standard, debhelper-supported way of doing so.

Absolutely.

> Thus far I see neither consensus, nor people driving improved copyright
> documentation. Instead I see Andreas' work being blocked[1] based on
> rules that aren't met by the rest of the archive either. And that's sad.

I agree.

Personally, although I am (as I say) dismayed at the poor state of our
archive, things have (apparently) been like this for years and nothing
terrible has come of it.  So I don't feel I now say that we should
suddenly start imposing a strict policy.

It is unfair to new packages to give old ones a free pass.  Some kind
of flexibility is perhaps justifiable, but at the very least if we are
going to block new packages, we need a recognition that the old
packages are also broken and a time-bounded decision to fix or remove
them.


We also have a problem that our decisionmaking process is not
working well.  I think that the right political process is:

ftpmaster and the release team should clearly tell us all whether bugs
of this kind are release critical, and/or reject/removal-worthy.

If they are determined to be RC or reject/removal-worthy, then we
should immediately file bugs of the appropriate severity of all the
popular packages that people in this thread have used as examples.

If the bugs are not determined to be RC or reject/removal-worthy, then
these issues seem to me to still be bugs.  If someone has the effort
to improve our tooling, and improve packages, their patches should be
accepted.

Ian.

use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Holger Levsen writes ("use long keyid-format in gpg.conf (Re: Key collisions in 
the wild"):
> I'm somewhat surprised by this mail… or rather by you appearantly
> knowing about the issue but still you seem to not have acted as advised,
> so let me repeat: everybody, please put "keyid-format long" into your
> ~/.gnupg/gpg.conf!

I am dismayed to once again see advice which suggests that systematic
security bugs in the default behaviour of gnupg should be addressed on
an ad-hoc basis by individual users editing their personal
configuration.

It would be much better to put out a stable release update to change
the default.  (Probably not a security update because of the risk of
causing currently-vulnerable scripts to become nonfunctional, which is
not something we normally do in security updates.)

Even if long keyids are not sufficient, they are a big improvement and
we should not let fixing this problem properly stand in the way of
doing what we can, now.

Ian.

Re: Key collisions in the wild

[Holger Levsen]

On Wed, Aug 10, 2016 at 12:09:40PM +0200, Jakub Wilk wrote:
> https://codesearch.debian.net/search?q=%5Cbgpg2%3F%5Cb.*--recv%28-keys%3F%29%3F%5Cs%2B%280x%29%3F%5B0-9a-fA-F%5D%7B8%7D%5Cb
> (And there's probably more that this simplistic search doesn't catch...)
 
thanks for that, I just fixed the simple example in debian-edu-doc for
wheezy, jessie and stretch…

> Any volunteers to file bugs?

the results list is much shorter than I expected, I'm almost tempted to
file bugs… (but then I already have a backlog of bugs I need to file…)

mysql-5.6_5.6.30-1/INSTALL-SOURCE
chromium-browser_52.0.2743.116-2/third_party/binutils/build-all.sh
softhsm2_2.1.0-3/WIN32-NOTES.md
softhsm2_2.1.0-3/WIN32-NOTES.md
softhsm2_2.1.0-3/WIN32-NOTES.md
debian-edu-doc_1.903~20160730/documentation/debian-edu-stretch/debian-edu-stretch-manual.pot
debian-edu-doc_1.903~20160730/documentation/debian-edu-jessie/debian-edu-jessie-manual.pot
phpmyadmin_4:4.6.3-1/doc/setup.rst
neurodebian_0.37.4/vm/d-i/wheezy/initial_setup
neurodebian_0.37.4/vm/d-i/jessie/initial_setup
neurodebian_0.37.4/vm/d-i/jessie/initial_setup
neurodebian_0.37.4/vm/d-i/tools/initial_setup
kivy_1.9.1-1/doc/sources/installation/installation-rpi.rst
grpc_0.11.1-1/tools/dockerfile/grpc_php_base/Dockerfile
samhain_3.1.0-7/deploy.sh.in
samhain_4.1.4-2/deploy.sh.in
samhain_4.1.4-2/deploy.sh.in
planner-el_3.43~20140112-2/planner-el.texi
vmm_0.6.2-1/doc/web/source/download.rst
samhain_3.1.0-7/deploy.sh.in
sks_1.1.6-1/BUGS


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Holger Levsen, on Wed 10 Aug 2016 10:26:09 +, wrote:
> I'm somewhat surprised by this mail… or rather by you appearantly
> knowing about the issue but still you seem to not have acted as advised,
> so let me repeat: everybody, please put "keyid-format long" into your
> ~/.gnupg/gpg.conf!

Well, I did in the end, yes, but I personally have never trusted these
IDs anyway, and would only trust signature paths.

Samuel

Re: Key collisions in the wild

[Samuel Thibault]

Sebastian Reichel, on Wed 10 Aug 2016 07:14:09 +0200, wrote:
> On Wed, Aug 10, 2016 at 12:47:43AM +0200, Samuel Thibault wrote:
> > As a late follow-up of the gpg key collision thread from debian-private
> > (but posted on debian-devel, there is nothing private here, I prefer to
> > see this information publicized actually):
> > 
> > € gpg --search-key samuel.thiba...@gnu.org
> > ...
> > (1) Samuel Thibault 
> > 4096 bit RSA key 7D069EE6, created: 2014-06-16
> > (2) Samuel Thibault 
> > 4096 bit RSA key 7D069EE6, created: 2010-09-14
> > 
> > So somebody *does* try to fake my gpg key too...
> 
> Looks like somebody uploaded the evil32 (https://evil32.com/)
> data to public keyservers.

Not all of evil32 apparently, there is not 6E520E81EA52ECF4 on
pgp.mit.edu for instance. Just looking at the people I've signed,
something like 1/4 of their clones have been uploaded.

Samuel

Re: Key collisions in the wild

[Ian Campbell]

On Wed, 2016-08-10 at 12:19 +0200, Jakub Wilk wrote:
> * Samuel Thibault , 2016-08-10, 01:17:
> > 
> > Samuel Thibault, on Wed 10 Aug 2016 00:47:43 +0200, wrote:
> > > 
> > > € gpg --search-key samuel.thiba...@gnu.org
> > > ...
> > > (1) Samuel Thibault 
> > > 4096 bit RSA key 7D069EE6, created: 2014-06-16
> > 
> > And it has 55 signatures from 55 colliding keys...
> 
> The forger botched it up, because all its signatures have almost the 
> same creation time. You can tell it's a sham key from quite a long
> way away.

A tool[0] which could scan pubrung.gpg (and friends) and warn about the
presence of such bad keys, perhaps based on an explicit blacklist of
the evil32 keys rather than heuristics about the creation times, would
be useful as a periodic hygiene check on my ~/.gnupg. Does such a thing
exist? Is it even possible?

Ian.

[0] thinking along the lines of openssl-vulnkeys or openssl-vulnkey.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Sam Morris]

On Wed, 10 Aug 2016 10:26:09 +, Holger Levsen wrote:

> Hi Samuel,
> 
> On Wed, Aug 10, 2016 at 12:47:43AM +0200, Samuel Thibault wrote:
>> As a late follow-up of the gpg key collision thread from debian-private
>> (but posted on debian-devel, there is nothing private here, I prefer to
>> see this information publicized actually):
>> 
>> € gpg --search-key samuel.thiba...@gnu.org
>> ...
>> (1) Samuel Thibault 
>> 4096 bit RSA key 7D069EE6, created: 2014-06-16
>> (2) Samuel Thibault 
>> 4096 bit RSA key 7D069EE6, created: 2010-09-14
>> 
>> So somebody *does* try to fake my gpg key too...
>> 
>> For the reminder,
>> https://gwolf.org/node/4070
> 
> I'm somewhat surprised by this mail… or rather by you appearantly
> knowing about the issue but still you seem to not have acted as advised,
> so let me repeat: everybody, please put "keyid-format long" into your
> ~/.gnupg/gpg.conf!
> 
> then, the output will look like this:
> 
> $ grep keyid-format .gnupg/gpg.conf 
> keyid-format long
> $ gpg --search-key samuel.thiba...@gnu.org
> ...
> (1) Samuel Thibault 
>   4096 bit RSA key E2992EA47D069EE6, created: 2014-06-16
> (2) Samuel Thibault 
> Samuel Thibault 
> Samuel Thibault 
> Samuel Thibault 
> Samuel Thibault 
>   4096 bit RSA key D0178C767D069EE6, created: 2010-09-14
> 
> 
> voila.

FYI, --search-key looks like this by default in 2.1. And when listing 
keys and in other operations, the output is even more verbose:

$ gpg2 -k sam@robots
pub   rsa4096 2014-04-08 [SC] [expires: 2019-04-07]
  CA1ACA69A83A892B1855D20B42025CDA27B9
uid   [ultimate] Sam Morris 
sub   rsa4096 2014-04-08 [E] [expires: 2019-04-07]

pub   dsa1024 2003-12-01 [SC] [expired: 2014-11-21]
  3412EA181277354B991BC869B2197FDB5EA01078
uid   [ expired] Sam Morris 

IMO this should be made consistent and the full fingerprint should be 
used for --search-key as it is with other operations, by default.

-- 
Sam Morris
https://robots.org.uk/
 
PGP: rsa4096/5CDA27B9
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

howto move threads away from -private@ (was: CLASSIFIED)

[Holger Levsen]

On Tue, Aug 09, 2016 at 12:52:33PM -0700, Steve Langasek wrote:
> Nothing I've written here is private.  You may quote me on a public mailing
> list, but not on debian-private ;)

LOL

that's a really good one, to be repeated many times.

thanks! :) (originally intended to send privately to just Steve, but
then realized I should cc:s some lists :-D


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Perl Configure mess (mostly) (Re: copyright precision)

[Ian Jackson]

Helmut Grohne writes ("Re: copyright precision"):
> On Tue, Aug 09, 2016 at 06:37:37PM +0100, Ian Jackson wrote:
> > Perl's Configure is not a very useful example and has IMO some
> > justification.  I think it's poor engineering to have edited the
> > output file, but that doesn't mean it's not now the source code.
> 
> IMO it is a very good example. To determine whether Perl[1]'s Configure
> is preferred form for modification, I sent a patch. It turned out that
> my patch couldn't be applied, because it touched generated parts and it
> was concluded[2] that Configure should be regenerated to fix the
> reported issue. Demonstrably, Configure is not preferred form for
> modification. Whether we call it source or not, the freedom to modify is
> practically lost.

My interpretation of the situation described in #762638 and #775940 is
that:

AIUI in the past, Perl upstream told people to edit Configure and
promised to accept patches in that form.  Debian took upstream at
their word.  We made extensive edits to Configure and never
regenerated it.

Now, upstream don't seem to be taking the same line.  But, we are
still using an edited output file.  If bugs occur in that file, we
will edit it further.  There is no intention on the part of Debian's
Perl maintainers to regenerate it, at least, not any time soon.

What this means is that we are using a fork of Configure.  The source
code for Debian's Perl Configure is the script itself.

Originally, we should not have accepted upstream's word.  When we did,
we started working on a non-source form of the work, effectively
forking it.  But now it is too late.

The same situation could in principle occur with minified concatenated
Javascript.  If some upstream package came with a copy of spong.js or
whatever which had been minified, prettified, and then substantially
edited, and for which the original creation process was no longer
available, then (regrettably) we would have to conclude that the
source for that version of spong.js was the file itself.  In practice
this is not likely to arise because of the different role of the file,
and because of the, err, different style of software release
management that Javascript programmers normally adopt.

I think it is fair (indeed, very wise) to block new occurrences of
this kind of problem.  I don't think it is sensible to try to throw
out packages containing existing occurrences.

For now, for Perl, I think my analysis shows that someone like you who
wants to improve Configure is entitled to produce a patch
(semi-automatically-generated, if necessary - in which case provide
the scripts or perl runes or whatever for records in BTS and source
package) to the Perl Configure.  The Perl maintainers should accept
it.

If anyone arranges to package metaconfig for Debian and to regenerate
Perl's Configure, your patch can simply be dropped on the grounds that
it's now unnecessary.  That would constitute us dropping our fork of
Configure.  But in the meantime, while we have that fork, we have to
allow people who need to edit it, to do so (and that includes
accepting their patches).


> Another place where the inability to build from source has hampered
> progress was blt #772590.

That's an instance of the old not-rerunning-autoconf chestnut.  There
are practical advantages providing a pregenerated configure (for
people who don't have a suitable autoconf), and practical problems
with providing a pregenerated file and then routinely overwriting it.

> Other packages that don't build from source by default include bash,
> dash, debianutils, dpkg, e2fsprogs, findutils, fribidi, gmp, jemalloc,
> libatomic-ops, libbsd, libtasn1-6, lzo2, ncurses, nettle, patch,
> readline6, and sed.

I agree that in general we should build from source.  Are these all
autoconf ?

> > Are you seriously suggesting that I actually propose a MBF ?
> 
> If you think that our current practice is wrong, isn't it logical to do
> so?

I'm not sure how I would even find all the packages affected.

And I agree with your other mail, about not filing bugs which no-one
will work on.


Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Adam D. Barratt]

On 2016-08-10 11:39, Ian Jackson wrote:

It would be much better to put out a stable release update to change
the default.  (Probably not a security update because of the risk of
causing currently-vulnerable scripts to become nonfunctional, which is
not something we normally do in security updates.)


Stable updates in point releases aren't fundamentally different in that 
respect to those issued via the security archive.


Regards,

Adam

Bug#833920: ITP: flask-restless -- Flask extension which provides simple generation of ReSTful JSON APIs

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flask-restless
  Version : 1.0.0b1
  Upstream Author : Jeffrey Finkelstein
* URL : https://github.com/jfinkels/flask-restless
* License : BSD or AGPLv3+
  Programming Lang: Python
  Description : Flask extension which provides simple generation of ReSTful 
JSON APIs

Flask-Restless is a Flask extension that provides simple generation of
ReSTful APIs that satisfy the JSON API specification given database
models defined using SQLAlchemy (or Flask-SQLAlchemy).


I intend to maintain the package within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXqxErMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYjLg//Q5Lx+NuPAf0YcHNw1QIy
bnh2tH5Qwd1sJ3nwTl4JYdDecUL5sm8m7oEBPThD/5uOi7Hu6e27W4P5x+YRCGTy
uBfu03n+btzCP85rTgQBINbbK3RpIxIiXOGf2WbKwHyex+ibTW6DzuHZ5otvLeJI
Ag6q+oRLOoTnqOjYWc3ul9uNw8U+pRpvig1KXQEN8XzwL3cPWLEA5vn5R001e0rh
vwKkvMv45ehzYhxlhwfSxrxIem28cs6q4U3BINXKOJj2t1HrN7PmYjQsprPY+z+D
hLg6zg3IsQlLAoWSDIjA9liwshNnf0IQzdtlDh32E/HwEnQp2UhPoSsuST1cuKiE
zwCjF2G4M4x+zQIsqg2xIrMRYr3OmWCqqAOrg7WzCM75hdF5iiSUEjIoGuD2sVl2
hO6zKOwiRbBWRgqj69+PxYL2mAOMewXGTmI21fd3PoXItU9yVFZ0cKX58VpqfmP7
lHxJvBO0fcLpxJ6bUk48GJG/fffsY5zAwwbdhlJgNNGmeCdHtU4OUfeMIngJwJ7v
kNHNIrUeGqtM89sYZ316RVGquRD7XPfpiywphSwE12G/4j6Zm6r/wOifQZYI2LML
cqcdZ4vNWVFMMoxfOUqGK+F8QVvxwGCooKq83IOm1FjCVM18JiF8L+xpQ0BS8yV9
1uhUG5WybIpIH2XnOBd2ycA=
=k0lG
-END PGP SIGNATURE-

Bug#833921: ITP: flask-compress -- Compress responses in your Flask app with gzip

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flask-compress
  Version : 1.3.0
  Upstream Author : William Fagan
* URL : https://github.com/wichitacode/flask-compress
* License : MIT
  Programming Lang: Python
  Description : Compress responses in your Flask app with gzip

Flask-Compress allows you to easily compress your Flask application's
responses with gzip.

The preferred solution is to have a server (like Nginx) automatically
compress the static files for you. If you don't have that option
Flask-Compress will solve the problem for you.


In intend to maintain the package within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXqxMoMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8paToA/+PKT9Bm9JXiTKbbyGZg9R
3QXR6ulc7BpihiPHpBQTt8nFKZGhuCyTxkJfQPnx/uZLGHqV72tmqyNLA2P9EgT3
gc3Nbst1BpsuU/WSavGYSJR+maxPD63ITCGM1fzzAW0gAzK6D5WWBqrkdIN/2qnx
r6kgrOQVd1smsU3eSvfyyE2GoUpIsEiM0iulajG1I4ETReJcE2cKeFsPb248fHPe
djM8w48AIy7bEjBkuuHB++d75OxIytSBo9ltVnOqtJoYJUp6bZzFL8aHQe2hzQK9
rFBtRNcXvTnZOhZqismtgLnHv1Yb855mJR5JHHUGGvPURiUprnopR3KSQdq29gvT
AhG77A+0lEb2MXii4jOo6xc8Aqud5+ZCYdrAESL/vf1phDKyUbIYeURZ+VrFNtJJ
LKZbyZzC+Js596CBw6E3yofoeBdElwo/3AMbDUcRXgqzmXInzzwqCcFiTpuXNynZ
jWU7YLSufuHj7K1LV7mFffNu1fgcfTFVGu+beDfV6OQvBM6QOapZXITRzDs0F+Iy
2PFqRk3CUG+yA1uIFarpI5LsRVZgAd0H0dzxbZ0vPzri21lKdb1g2jPgwgMJCdK3
9kL8Z2x9JF0hVOmYeNstmwUtyvIZa2SC2WxqzhlYqTz4dAqbv9cmp4e1Rnqu7Dwe
4b7ZbmmENi+Tl1jcpE+H97I=
=xDZt
-END PGP SIGNATURE-

Bug#833922: ITP: flask-ldapconn -- LDAP connection and ORM for Flask Applications

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flask-ldapconn
  Version : 0.6.13
  Upstream Author : Rafael Römhild
* URL : http://github.com/rroemhild/flask-ldapconn
* License : BSD
  Programming Lang: Python
  Description : LDAP connection and ORM for Flask Applications

Flask-LDAPConn is a Flask extension providing ldap3 (an LDAP V3 pure
Python client) connection for accessing LDAP servers.

To abstract access to LDAP data this extension provides a simple ORM
model.


In intend to maintain the package within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJXqxRKMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYpfg//Yev9If4IafH30athGAqf
AySEtCUlRv7/nfchHl+b62V5aXWQzu7LPzqrLlsuTKsPJm6UFun3uWb78REFKEGD
Ah/37lLRgQn5gTgwqSeksUBcS/PhiZ//1S8yHl4HCEVDfnWvlFiqiYQdizX+PGDj
zwQnJxvQFoqkUdZnbUqjccAa1dWQZw/hNwSQAs+SbrdxT8jKGdznE6TsMLh0tWS0
SmF7KkVko4G/uQz100UdNqiyVobv9HxiKAgMvhMjLSMNF6d7IGyLKYr4bVP3tl7g
P4chtX3tNHeJyx9i+w6SG9kefRoZjS5SIxyfP1p/dTcgoEVS7eTHo/jEBRFCSLty
c/W7eImwkb9dwhamDMP+56IgTOcNcyljZddqsqqrY1nfnqJj0QhOhfDlurpo/aBX
DyAuwVwatv70wSpL1kF25RNzz00PohYvkUdxabXs81538u0Z4PYZDKB+It+7nlGx
FNM2YkahgIhFFApWjmDKAZJFwIR+LOrcTflTKbJdjjyA+5xy5rIqHPnn7bnD9Reo
h914PHP7pZEQb3cJhzjvBcbIPoQJrYEe3M69j+deQAnjTJcFmXX+/ragP9/KJpU7
DV+m/tJQeeX/mhB03u9I7gtZGlWOKS02dThVjQA9XTvN5o/t64HeeTtUKcHUi8XX
sGaBkO6rVjcSE3Gi1QKPy0Y=
=AmnQ
-END PGP SIGNATURE-

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> On 2016-08-10 11:39, Ian Jackson wrote:
> > It would be much better to put out a stable release update to change
> > the default.  (Probably not a security update because of the risk of
> > causing currently-vulnerable scripts to become nonfunctional, which is
> > not something we normally do in security updates.)
> 
> Stable updates in point releases aren't fundamentally different in that 
> respect to those issued via the security archive.

I was under the impression that the intent was that there was a
meaningful distinction in the level of conservativeness between "take
security updates" and "take security updates and stable updates too".

If that's not the case, then I don't understand what the distinction
is.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Samuel Thibault, on Wed 10 Aug 2016 12:46:07 +0200, wrote:
> Holger Levsen, on Wed 10 Aug 2016 10:26:09 +, wrote:
> > I'm somewhat surprised by this mail… or rather by you appearantly
> > knowing about the issue but still you seem to not have acted as advised,
> > so let me repeat: everybody, please put "keyid-format long" into your
> > ~/.gnupg/gpg.conf!
> 
> Well, I did in the end, yes, but I personally have never trusted these
> IDs anyway, and would only trust signature paths.

And actually, moving to 64bit fingerprints by default is possibly not a
good idea: who knows when 64bit will not be secure any more? Estimating
very roughly, if a 32bit collision can be found within a few seconds
with one GPU now as evil32 seems to show, a supercomputer with 1
GPUs can find a 64bit collision within a month...

Really, only signature paths should be looked at by people, and it seems
like we are tending to let people think 64bit fingerprints are "secure".

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Adam D. Barratt]

On 2016-08-10 12:55, Ian Jackson wrote:

Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re:
Key collisions in the wild"):

On 2016-08-10 11:39, Ian Jackson wrote:
> It would be much better to put out a stable release update to change
> the default.  (Probably not a security update because of the risk of
> causing currently-vulnerable scripts to become nonfunctional, which is
> not something we normally do in security updates.)

Stable updates in point releases aren't fundamentally different in 
that

respect to those issued via the security archive.


I was under the impression that the intent was that there was a
meaningful distinction in the level of conservativeness between "take
security updates" and "take security updates and stable updates too".

If that's not the case, then I don't understand what the distinction
is.


That depends on what you mean by "stable updates". If you mean those 
announced via debian-stable-announce@ then the primary difference is 
that they don't need to be (and often won't be) security-related. If 
you're talking about point releases, then from a security perspective 
the fundamental difference is the speed at which updates are made 
available to users.


Not all security updates are released via the security archive, but the 
difference is more likely to be a result of the manpower available to 
handle managing and releasing such updates and the perceived impact of 
the vulnerability. "We" assume that the majority of users will upgrade 
to stable point releases once they're available and there's a 
corresponding expectation on the part of our users as to what kind of 
updates will be included; the decision as to whether to break existing 
setups shouldn't be fundamentally different simply based on how the 
update was released.


Regards,

Adam

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> [explanation]

Thanks.

I don't know what side of this (one) line such a proposed gpg change
falls.  I still think it's unsatisfactory that our stable release has
a default behaviour which cannot be used safely.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > [explanation]
> 
> Thanks.
> 
> I don't know what side of this (one) line such a proposed gpg change
> falls.  I still think it's unsatisfactory that our stable release has
> a default behaviour which cannot be used safely.

Well, I'd argue that 64bit IDs are not safe either, they have not been
made to be.

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Christian Seiler]

On 08/10/2016 03:19 PM, Samuel Thibault wrote:
> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
>> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
>> collisions in the wild"):
>>> [explanation]
>>
>> Thanks.
>>
>> I don't know what side of this (one) line such a proposed gpg change
>> falls.  I still think it's unsatisfactory that our stable release has
>> a default behaviour which cannot be used safely.
> 
> Well, I'd argue that 64bit IDs are not safe either, they have not been
> made to be.

Can we even consider key fingerprints safe in the long run? AIUI they
are SHA1 hashes of the public key, and while there isn't a feasible
preimage attack on SHA1 _yet_ (and we shouldn't panic), there's a
reason why SHA1 is discouraged by experts.

Regards,
Christian

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Christian Seiler writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> On 08/10/2016 03:19 PM, Samuel Thibault wrote:
> > Well, I'd argue that 64bit IDs are not safe either, they have not been
> > made to be.
> 
> Can we even consider key fingerprints safe in the long run? AIUI they
> are SHA1 hashes of the public key, and while there isn't a feasible
> preimage attack on SHA1 _yet_ (and we shouldn't panic), there's a
> reason why SHA1 is discouraged by experts.

This is precisely the kind of point I was thinking of when I wrote:

  Even if long keyids are not sufficient, they are a big improvement and
  we should not let fixing this problem properly stand in the way of
  doing what we can, now.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Christian Seiler, on Wed 10 Aug 2016 15:37:43 +0200, wrote:
> On 08/10/2016 03:19 PM, Samuel Thibault wrote:
> > Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> >> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> >> collisions in the wild"):
> >>> [explanation]
> >>
> >> Thanks.
> >>
> >> I don't know what side of this (one) line such a proposed gpg change
> >> falls.  I still think it's unsatisfactory that our stable release has
> >> a default behaviour which cannot be used safely.
> > 
> > Well, I'd argue that 64bit IDs are not safe either, they have not been
> > made to be.
> 
> Can we even consider key fingerprints safe in the long run?

Well, I'd say that in the end people *have* to cryptographically check
the signatures, and not trust fingerprints.

Thinking about it, I'd say we could even instead *shorten* the default
ID to 16bit, so that people will hopefully simply just not trust them at
all. For practical uses, 16bit hashing is enough to manage one's public
keyring.

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Christian Seiler]

On 08/10/2016 03:44 PM, Samuel Thibault wrote:
> Christian Seiler, on Wed 10 Aug 2016 15:37:43 +0200, wrote:
>> On 08/10/2016 03:19 PM, Samuel Thibault wrote:
>>> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
 Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
 collisions in the wild"):
> [explanation]

 Thanks.

 I don't know what side of this (one) line such a proposed gpg change
 falls.  I still think it's unsatisfactory that our stable release has
 a default behaviour which cannot be used safely.
>>>
>>> Well, I'd argue that 64bit IDs are not safe either, they have not been
>>> made to be.
>>
>> Can we even consider key fingerprints safe in the long run?
> 
> Well, I'd say that in the end people *have* to cryptographically check
> the signatures, and not trust fingerprints.

Every key signing I've done so far has relied on verifying that the
fingerprint matches in some way or another.

> Thinking about it, I'd say we could even instead *shorten* the default
> ID to 16bit, so that people will hopefully simply just not trust them at
> all. For practical uses, 16bit hashing is enough to manage one's public
> keyring.

>From my experience with how UX works in practice, I think this will
not work at all and be rather counter-productive. I think Ian's
proposal to use 64bit for now as a stop-gap measure is actually
the best short-term solution to increase security.

Regards,
Christian

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Carlos Alberto Lopez Perez]

On 10/08/16 15:19, Samuel Thibault wrote:
> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
>> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
>> collisions in the wild"):
>>> [explanation]
>>
>> Thanks.
>>
>> I don't know what side of this (one) line such a proposed gpg change
>> falls.  I still think it's unsatisfactory that our stable release has
>> a default behaviour which cannot be used safely.
> 
> Well, I'd argue that 64bit IDs are not safe either, they have not been
> made to be.
> 
> Samuel
> 
> 

Upstream has introduced -keyid-format=none which shows the full fingerprint,
and then made it the default.

Issue: [default to --with-fingerprint, introduce --without-fingerprint]
https://bugs.gnupg.org/gnupg/issue2379

Commit: [gpg: Implement --keyid-format=none.]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b047388

Commit: [gpg: Use --keyid-format=none by default.]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=7257ea2


This seems much safer than 64bit IDs.


Maybe a backport of this is feasible?




signature.asc
Description: OpenPGP digital signature

Re: Key collisions in the wild

[Paul Wise]

On Wed, Aug 10, 2016 at 6:09 PM, Jakub Wilk wrote:

> (And there's probably more that this simplistic search doesn't catch...)

apt-key usage for instance:

https://codesearch.debian.net/search?q=\bapt-key\b.*--recv%28-keys%3F%29%3F\s%2B%280x%29%3F[0-9a-fA-F]{8}\b

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: copyright precision

[Simon McVittie]

On Wed, 10 Aug 2016 at 11:12:55 +0800, Paul Wise wrote:
> The only possible way to solve this in general terms is, accurate
> document the copyright/license of the source package using the
> machine-readable format and during builds, track the transformation of
> input files in the source package to output files in the binary
> package and then generate the copyright/license information for the
> binary package based on which input files from which source/binary
> packages ended up in the new binary package.

I'm sure this is a very interesting academic exercise, but pragmatically,
why do we want to require ourselves to go to all that effort? For that
matter, is everything we require *now* necessary or desirable?

Broadly, we have two reasons (that I'm aware of) to do legal stuff:
because we want to (it meets some goal that we care about - self-imposed
policy), and because lawyers tell us we are at risk of being sued if we
don't (it meets our goal of being able to continue making Debian -
license compliance).

For software with a reasonably helpful upstream and a reasonably sane
build system, I've often found that jumping through the necessary
hoops to write debian/copyright takes about as long as the rest of the
packaging put together. This is demotivating: I didn't join this project
to copy copyright information around, I joined this project to make an
operating system.

If I have to copy copyright information around to meet our project's
goals (including the goal of obeying copyright law, both because we
want to respect authors' rights and because we don't want to get sued)
then I'll put up with it - but I think we should be clear about why we
do this work, and only require maintainers to do exactly enough of it
to meet its actual goals.

In particular, if this thread comes to the conclusion that more needs to
be done than what maintainers currently do, then it should be something
actionable; and since it will likely create more work for a very large
number of people, it should be backed up by *why* that work is needed.

If the reason turns out to be a ftp-master saying "we have received
legal advice saying that you must do x, y and z, and we are not allowed to
explain further", then that would be unsatisfying but better than nothing;
and at least it would put a boundary on it.

---

Self-imposed policy of DFSG compliance:

One core value in Debian is that all of main is DFSG-compliant.
If we assume that maintainers (and ftpmasters) check the licenses of our
source packages as they are meant to do, and we build all of main's
binary packages from source code in main and other binaries from main,
then all of main that is distributable is trivially DFSG-compliant.

(Some of it might be non-distributable, for instance by being a derived
work of both OpenSSL and something GPL'd; but that's license-compliance,
and we frequently already detect it.)

---

Self-imposed policy of documenting copyright information:


says "Every package must be accompanied by a verbatim copy of its
copyright information and distribution license", which contains an
implicit assumption that each package *has* a single distribution license.

This is clearly not actually true in practice. The DEP-5 specification
addresses this by allowing the copyright file to specify multiple licenses
which must be complied with simultaneously. Optionally, it also lets the
maintainer specify the licenses of individual source files matched by
filename or glob.

The ftp-masters appear to have interpreted "copyright information" to
require a verbatim quotation of the license grant, except in cases
where there are several similar license grants with trivial differences.
I'm still not clear on why this is, and whether it's because we want to
or because we'll get sued if we don't.

Some of our Policy-compliant copyright files are clearly absurd;
adwaita-icon-theme's is 88K and lists at least over 200 (potential)
copyright holders, mostly for l10n. I find it hard to believe that all
of that is actually necessary or achieving a desirable goal for us.
Meanwhile, linux's copyright file resorts to citing "Linus Torvalds
and many others" as copyright holders. If the kernel was held to the
same standard that is (anecdotally) applied to most other packages,
its copyright file would presumably be impractically huge (or perhaps
more likely, we would no longer have any volunteers willing to either
maintain a Linux kernel package or review it in NEW).

DEP-5 notably omits any syntax for describing the copyright or licenses of
the contents of the *binary* package, which suggests that its authors
(even those who consider it most valuable to specify the licenses of
individual source files) did not consider this to be a goal.
Are we aiming to go further than this by documenting, for instance,
which specific DFSG-compliant license applies to /usr/bin/dbus-daemon,
which specific DFSG-compliant license ap

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> > I don't know what side of this (one) line such a proposed gpg change
> > falls.  I still think it's unsatisfactory that our stable release has
> > a default behaviour which cannot be used safely.
> 
> Well, I'd argue that 64bit IDs are not safe either, they have not been
> made to be.

This is precisely the kind of point I was thinking of when I wrote:

  Even if long keyids are not sufficient, they are a big improvement and
  we should not let fixing this problem properly stand in the way of
  doing what we can, now.

This is now the second time I have cut and pasted that into this
thread.  I feel frustrated.

Did you miss that paragraph the first two times (in which case I guess
me repeating it was useful) ?  Or did you disagree with me ?  If you
disagreed, it would be helpful if you explained why, and what you
think we should do for users of jessie.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Ian Jackson, on Wed 10 Aug 2016 18:56:52 +0100, wrote:
> Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> > > I don't know what side of this (one) line such a proposed gpg change
> > > falls.  I still think it's unsatisfactory that our stable release has
> > > a default behaviour which cannot be used safely.
> > 
> > Well, I'd argue that 64bit IDs are not safe either, they have not been
> > made to be.
> 
> This is precisely the kind of point I was thinking of when I wrote:
> 
>   Even if long keyids are not sufficient, they are a big improvement and
>   we should not let fixing this problem properly stand in the way of
>   doing what we can, now.
> 
> This is now the second time I have cut and pasted that into this
> thread.  I feel frustrated.
> 
> Did you miss that paragraph the first two times (in which case I guess
> me repeating it was useful) ?

I missed it, yes, sorry.

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> Ian Jackson, on Wed 10 Aug 2016 18:56:52 +0100, wrote:
> > Did you miss that paragraph the first two times (in which case I guess
> > me repeating it was useful) ?
> 
> I missed it, yes, sorry.

Thanks.  I feel less frustrated now.  I hope you don't feel shouted
at...

Regards,
Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Ian Jackson, on Wed 10 Aug 2016 19:06:28 +0100, wrote:
> Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > Ian Jackson, on Wed 10 Aug 2016 18:56:52 +0100, wrote:
> > > Did you miss that paragraph the first two times (in which case I guess
> > > me repeating it was useful) ?
> > 
> > I missed it, yes, sorry.
> 
> Thanks.  I feel less frustrated now.  I hope you don't feel shouted
> at...

No problem :)

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Gunnar Wolf]

Samuel Thibault dijo [Wed, Aug 10, 2016 at 02:03:33PM +0200]:
> And actually, moving to 64bit fingerprints by default is possibly not a
> good idea: who knows when 64bit will not be secure any more? Estimating
> very roughly, if a 32bit collision can be found within a few seconds
> with one GPU now as evil32 seems to show, a supercomputer with 1
> GPUs can find a 64bit collision within a month...
> 
> Really, only signature paths should be looked at by people, and it seems
> like we are tending to let people think 64bit fingerprints are "secure".

That's the reason why a key by itself means little, but we do place
value on the web of trust around it. If a given 64-bit keyid takes a
month to generate¹, and the uploading developers keyring is somewhere
around the 820 keys (from which around 700 make up the strong set), it
would still take ~60 years to generate our full strong set of evil
twins. This is not trivial time.

Of course, Evil32 started aided with the power of numbers — It's not
that they search to make a evil-twin of every 32-bit keyid, but that
they generate keys as fast as they can, and just discard any key not
matching an existing keyid. The keyserver network currently carries
over 4.3 million keys, so roughly one every thousand generated keys
will match *something*¹. Of course, Evil32 is interested in the
keyservers' strong set, which I guess will be way smaller (but have no
numbers to back my hopes).

I believe we are safe to use 64-bit keys *for the time being*. Of
course, nobody will imply that it's as safe to use 64-bit as
160-bit. We should end accepting that human-usable keyids are not
worth their salt and move to full-fingerprint. But there are many
things to fix before that... Among them (and I might be mistaken here)
the PGP key format itself, as AFAICT signatures are stored based on
their long keyid (and not on full hashes)!

--

¹ Yes, the keyserver network carries several already collided keys —
  Such as the ones that prompted this thread!

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Gunnar Wolf]

Gunnar Wolf dijo [Wed, Aug 10, 2016 at 02:08:12PM -0500]:
> That's the reason why a key by itself means little, but we do place
> value on the web of trust around it.
> (...blah...)

Anyway, I managed to twist my mail with many facts and make it into a
long mess :) That was my main point. Nobody should trust my key to be
"just" even AB41C1C68AFD668CA045EBF8673A03E4C1DB921F — It's not yet
feasible to willingly create a collision, but by mere chance, somebody
might just find it on their next key generation. My identity should be
trusted based on this long number plus the web of trust around
it.

It is highly unlikely somebody will find a collision with my
fingerprint by itself, but it's mindboggingly stupidly utterly
bloody unlikely some will find two, three other (even 64-bit)
collisions to sign my fake with. And I have over a hundred ;-)


signature.asc
Description: Digital signature

Re: Status of kbd console-data and console-setup

[Samuel Thibault]

Hello,

Cesare Leonardi, on Sun 31 Jul 2016 16:22:54 +0200, wrote:
> Console-data package was last updated in 2014, was reported obsolete for a
> long time and user reporting bug to it are sollecited to migrate to
> console-setup. For example see the preistoric bug #626680 (still valid). And
> upstream looks definitely dead.
> Why this broken package is still available?

Perhaps for some corner cases. It's meant to be removed anyway.

> Nowadays localectl from systemd coupled with kbd are able to cover the main
> job of console-setup, isn't it?

I don't think so. Does it support the various modifiers that xkb
supports, for instance? Does it cover at least the same set of keymaps
as xkb? Are kbd keymaps really as well maintained as xkb-data keymaps
are?

> I mean setting up console's and X11's keyboard.

Does systemd now sets up X11 keyboard too?!

Using console-setup has allowed Debian to configure both console and X11
keyboard exactly the same way, with the same xkb-data keymaps. Using the
kbd keymaps would strongly depart from this, wouldn't it?

Samuel

PO#: 001238

[WeTransfer]

 - This mail is in HTML. Some elements may be ommited in plain text. -

Hello,
You have received PO#: 001238 from
POSH COMPANY LLC,
that were uploaded to you through the WeTransfer. use the link below to 
download the Purchase Order on Adobe Pdf.
CLICK HERE
WeTransfer Plus!

Re: copyright precision

[Ian Jackson]

Simon McVittie writes ("Re: copyright precision"):
> I'm sure this is a very interesting academic exercise, but pragmatically,
> why do we want to require ourselves to go to all that effort? For that
> matter, is everything we require *now* necessary or desirable?

Thanks for your excellent article.  It is IMO a very valuable
contribution to this conversation.

Also, I can find nothing in it to disagree with :-).

> ---
> Self-imposed policy of documenting copyright information:

Personally, I think it would be much better if binary packages had
accurate centrally findable statements of their authorship
information.  For the purposes of giving credit (which is something I
_want_ us to be doing) rather than some kind of legal compliance.

But there are many many things that I think Debian could do much
better.  I certainly don't feel I personally want to put doing this
work anywher enear the top of my personal Debian todo list list (or
even my to-do-sometime-maybe list).

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Please, provide a fixed Cloud Image URL for Debian

[Martinx - ジェームズ]

Guys,

 When we talk about Cloud Images for OpenStack, both Ubuntu and CentOS
provides fixed URLs that never changes.

 This way, we can easily automate Glance to download images by demand, we
can have new images, without adding new images into glance!

 Exemplifying:


 CentOS 6/7 fixed image URL:

 http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c
 http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2c

 Ubuntu 16.04 fixed image URL:


http://uec-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.img


 Then, on Glance, here is how I'm adding those images:


  - glance image-create --location
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2c
--name "CentOS 7 - 64-bit - Cloud Based Image" --is-public true
--container-format bare --disk-format qcow2
  - glance image-create --location
http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c
--name "CentOS 6 - 64-bit - Cloud Based Image" --is-public true
--container-format bare --disk-format qcow2

 - glance image-create --location
http://uec-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.img
--name "Ubuntu 16.04 LTS - Xenial Xerus - 64-bit - Cloud Based Image"
--is-public true --container-format bare --disk-format qcow2


 I'm using my own Ansible automation to do this:


https://github.com/sandvine-eng/svauto/blob/dev/ansible/roles/os_glance_images/tasks/main.yml


 The problem with Debian is that there is no fixed URL! Debian images
disappears from time to time, which breaks my automation and that "Glance
download by demand feature", like this:

 Debian 8.5 image URL:



http://cdimage.debian.org/cdimage/openstack/8.5.0/debian-8.5.0-openstack-amd64.qcow2

 This image will be gone, soon as Debian launches 8.6.0!!! This is bad.


 So, can Debian provides something like this:


http://cdimage.debian.org/cdimage/openstack/8/debian-8-openstack-amd64.qcow2
that always points to the latest stable release image of 8 series (Jessie)?


 For example, this:

 http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c
pointed to CentOS 6.7, but now, it is 6.8! Glance will download the new
image, without any human action.


 Hope that Debian provides something similar!

Cheers!
Thiago

Re: Please, provide a fixed Cloud Image URL for Debian

[Clint Byrum]

Excerpts from Martinx - ジェームズ's message of 2016-08-10 17:58:05 -0400:
> Guys,
> 
>  When we talk about Cloud Images for OpenStack, both Ubuntu and CentOS
> provides fixed URLs that never changes.
> 
>  This way, we can easily automate Glance to download images by demand, we
> can have new images, without adding new images into glance!
> 
>  Exemplifying:
> 
> 
>  CentOS 6/7 fixed image URL:
> 
>  http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c
>  http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2c
> 
>  Ubuntu 16.04 fixed image URL:
> 
> 
> http://uec-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.img
> 
> 
>  Then, on Glance, here is how I'm adding those images:
> 
> 
>   - glance image-create --location
> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2c
> --name "CentOS 7 - 64-bit - Cloud Based Image" --is-public true
> --container-format bare --disk-format qcow2
>   - glance image-create --location
> http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c
> --name "CentOS 6 - 64-bit - Cloud Based Image" --is-public true
> --container-format bare --disk-format qcow2
> 
>  - glance image-create --location
> http://uec-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.img
> --name "Ubuntu 16.04 LTS - Xenial Xerus - 64-bit - Cloud Based Image"
> --is-public true --container-format bare --disk-format qcow2
>

FYI, you've just told the whole world that all they need to do is
flood your DNS resolver with responses to uec-images.ubuntu.com or
cloud.centos.org, and they can make your Ubuntu and CentOS users run
their own trojaned Ubuntu and CentOS images.

You need to go through the act of downloading, verifying, and uploading
your images. Automation can do that, but in that case, the automation
can also handle Debian's image scheme.

> 
>  I'm using my own Ansible automation to do this:
> 
> 
> https://github.com/sandvine-eng/svauto/blob/dev/ansible/roles/os_glance_images/tasks/main.yml
> 
> 
>  The problem with Debian is that there is no fixed URL! Debian images
> disappears from time to time, which breaks my automation and that "Glance
> download by demand feature", like this:
> 
>  Debian 8.5 image URL:
> 
> 
> 
> http://cdimage.debian.org/cdimage/openstack/8.5.0/debian-8.5.0-openstack-amd64.qcow2
> 
>  This image will be gone, soon as Debian launches 8.6.0!!! This is bad.
> 
> 
>  So, can Debian provides something like this:
> 
> 
> http://cdimage.debian.org/cdimage/openstack/8/debian-8-openstack-amd64.qcow2
> that always points to the latest stable release image of 8 series (Jessie)?
> 
> 
>  For example, this:
> 
>  http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c
> pointed to CentOS 6.7, but now, it is 6.8! Glance will download the new
> image, without any human action.
> 


I think a fixed URL for downloading images of major versions would in
fact be good. But you still need to verify the integrity of that image,
for the internet is dark, and full of terrors.

Re: Please, provide a fixed Cloud Image URL for Debian

[Adam Heath]

On 08/10/2016 05:18 PM, Clint Byrum wrote:

I think a fixed URL for downloading images of major versions would in
fact be good. But you still need to verify the integrity of that image,
for the internet is dark, and full of terrors.



Verification of the existing images has to happen regardless; having a 
stable url has nothing at all to do with that.  You're conflating issues.

Re: Please, provide a fixed Cloud Image URL for Debian

[Clint Byrum]

Excerpts from Adam Heath's message of 2016-08-10 17:34:36 -0500:
> On 08/10/2016 05:18 PM, Clint Byrum wrote:
> > I think a fixed URL for downloading images of major versions would in
> > fact be good. But you still need to verify the integrity of that image,
> > for the internet is dark, and full of terrors.
> >
> 
> Verification of the existing images has to happen regardless; having a 
> stable url has nothing at all to do with that.  You're conflating issues.

Correct that the verification has to happen. But, the OP was suggesting
that he just tells OpenStack's glance service to download these images
directly from the internet on his hypervisor hosts (which is what
--location does). This means that no verification happens before the VM
boots. The image is downloaded, turned into a filesystem for a VM, and
booted, without ever having consulted a list of cryptographic hashes,
gpg key, or even a crc32. :-/

Re: Please, provide a fixed Cloud Image URL for Debian

[Jeremy Stanley]

On 2016-08-10 16:16:54 -0700 (-0700), Clint Byrum wrote:
[...]
> the OP was suggesting that he just tells OpenStack's glance
> service to download these images directly from the internet on his
> hypervisor hosts (which is what --location does). This means that
> no verification happens before the VM boots. The image is
> downloaded, turned into a filesystem for a VM, and booted, without
> ever having consulted a list of cryptographic hashes, gpg key, or
> even a crc32. :-/

And what's worse, the example was of doing it over plain HTTP, no
TLS even (for whatever transport security is worth anyway).
-- 
Jeremy Stanley

Bug#833975: ITP: libjs-jquery-stupidtable -- jQuery table sorting plugin

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: libjs-jquery-stupidtable
  Version : 1.0.1
  Upstream Author : Joseph McCullough
* URL : https://github.com/joequery/Stupid-Table-Plugin
* License : Expat
  Programming Lang: JavaScript
  Description : jQuery table sorting plugin

 Most table sorting plugins try to account for a limitless number of
 data types and their limitless ways of being presented. This leads to
 an extremely bloated code base with only a tiny portion of the code
 ever used by your project.
 .
 This plugin avoids that issue by letting you define your own ways of
 sorting table columns. The plugin internally recognizes "int",
 "string", "string-ins" (case-insensitive) and "float", so simple data
 tables will take very little effort on your part.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#833976: ITP: libjs-jquery-dotdotdot -- jQuery plugin for ellipsis on multiple line content

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: libjs-jquery-dotdotdot
  Version : 1.8.3
  Upstream Author : Fred Heusschen
* URL : https://github.com/FrDH/jQuery.dotdotdot
* License : Expat
  Programming Lang: JavaScript
  Description : jQuery plugin for ellipsis on multiple line content

 A jQuery plugin for advanced cross-browser ellipsis which handles
 multiple line contents depending on whether the text will overlap an
 element.
 .
 You can also add one or several CSS classes to HTML elements to
 automatically invoke the plugin's functionality and some extra
 features.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

deprecating apt-key (was: Re: Key collisions in the wild)

[Johannes Schauer]

Hi,

Quoting Paul Wise (2016-08-10 17:32:15)
> On Wed, Aug 10, 2016 at 6:09 PM, Jakub Wilk wrote:
> > (And there's probably more that this simplistic search doesn't catch...)
> 
> apt-key usage for instance:
> 
> https://codesearch.debian.net/search?q=\bapt-key\b.*--recv%28-keys%3F%29%3F\s%2B%280x%29%3F[0-9a-fA-F]{8}\b

these should be fixed anyways because "the programatic usage [of apt-key] is
strongly discouraged" (according to the apt-key man page and apt developers on
IRC). I recently removed apt-key usage from sbuild after having consulted with
the apt maintainers. They explained that they mean something even stronger than
deprecation by writing "strongly discouraged".

Instead, keys should directly be placed in /etc/apt/trusted.gpg.d in the base64
encoded format. Converting keys from armored ASCII format to the base64 encoded
format (the format that gpgv understands) can even be done from a shell script
without gnupg [1]:

awk '/^$/{ x = 1; } /^[^=-]/{ if (x) { print $0; } ; }' | base64 -d

Or with gnupg:

gpg --dearmor pubkey.asc

A nice thing about the latter gpg command is, that it also does the right thing
on keys that already are dearmored, so no detection of key format is needed.

Thanks!

cheers, josch

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831409#67


signature.asc
Description: signature

Re: Please, provide a fixed Cloud Image URL for Debian

[Paul Wise]

On Thu, Aug 11, 2016 at 5:58 AM, Martinx - ジェームズ wrote:

>  When we talk about Cloud Images for OpenStack, both Ubuntu and CentOS
> provides fixed URLs that never changes.

BTW, there is a debian-cloud mailing list for Cloud discussions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise