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
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%
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
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
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
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 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 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
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:
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
- 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!
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
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
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
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 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 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 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
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
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 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 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
>>>
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]
>
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
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
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
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
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
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
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
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
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-restless
Version : 1.0.0b1
Upstream Author : Jeffrey Finkelstein
* URL : https://github.com/jfinkels/flask-restless
* License : BSD or
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
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 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
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 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
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, 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 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
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
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
* 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
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
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
47 matches
Mail list logo
