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 fi
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
* 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, be
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 samue
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
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" i
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 si
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,
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 inform
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: 20
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 t
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 St
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 no
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
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
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
Progra
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
Program
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
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, p
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
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
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 unsatis
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 pro
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
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]
>
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
>>>
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
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.debia
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 t
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
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
> > > f
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.
Tha
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
> > >
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
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 sh
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
> upst
- 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!
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
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:
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, w
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;
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
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
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
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
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%
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
47 matches
Mail list logo
