❦ 13 juillet 2014 11:52 +0800, Thomas Goirand :
>> As libressl is currently under heavy development, it is imho not to
>> be expected to have that stable ABI you are asking for.
>
> Well, I don't agree with this view. If LibreSSL pretends to be a
> replacement for OpenSSL, then they should care
❦ 12 juillet 2014 23:08 +0100, Steve McIntyre :
> And I've got to ask: for the couple of trivial examples that Frederick
> pointed out - why on earth do these even exist as libraries instead of
> being inlined wherever they're needed?
Because, in node, a library is cheap and the functionality g
On Sun, 13 Jul 2014 09:26:38 +0200
Vincent Bernat wrote:
> ❦ 12 juillet 2014 23:08 +0100, Steve McIntyre :
>
> > And I've got to ask: for the couple of trivial examples that
> > Frederick pointed out - why on earth do these even exist as
> > libraries instead of being inlined wherever they're
At Sun, 13 Jul 2014 09:26:38 +0200,
Vincent Bernat wrote:
>
> ❦ 12 juillet 2014 23:08 +0100, Steve McIntyre :
>
> > And I've got to ask: for the couple of trivial examples that Frederick
> > pointed out - why on earth do these even exist as libraries instead of
> > being inlined wherever they'r
At Sat, 12 Jul 2014 14:46:45 +0200,
Toni Mueller wrote:
> On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote:
>
> > I'm not really sure what you mean by this. I'm pretty sure the
> > openssl development team has a pretty good understanding of
> > security and I don't see anybody adding a
On 07/13/2014 02:17 PM, Matthias Urlichs wrote:
> Does gnutls have an openssl shim which actually works as a generic
> replacement? I dimly recall a couple of not-so-nice incompatibilities
As much as I understand, it's a complete alternative with a different
API, I don't think there's a compatibil
Matthias Urlichs wrote:
> Thomas Goirand:
[...]
>> As Kurt wrote, GNUTLS becomes a better alternative then.
> Does gnutls have an openssl shim which actually works as a generic
> replacement? I dimly recall a couple of not-so-nice incompatibilities …
I am not aware of recent any changes to the O
Cyril Brulebois dixit:
>Thorsten Glaser (2014-07-12):
>> OK, can you please give-back makefs on mips once the new bmake
>> binaries are available for all buildds?
>
>Please send your request to the appropriate place.
Ookay. Yes, this was a mistake of mine. But it took me about
six minutes t
On Sun, Jul 13, 2014 at 08:17:51AM +0200, Matthias Urlichs wrote:
> Hi,
>
> Thomas Goirand:
> > Well, I don't agree with this view. If LibreSSL pretends to be a
> > replacement for OpenSSL, then they should care about being ABI
> > compatible, so we can easily switch from one implementation to the
Thorsten Glaser (2014-07-13):
> Cyril Brulebois dixit:
>
> >Thorsten Glaser (2014-07-12):
>
> >> OK, can you please give-back makefs on mips once the new bmake
> >> binaries are available for all buildds?
> >
> >Please send your request to the appropriate place.
>
> Ookay. Yes, this was a
On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote:
> > > I think GnuTLS is actually a better alternative and wish there
> > > were more people developing and using it.
[...]
> > * GnuTLS, with an API incompatible with OpenSSL, thus requiring huge
> >amounts of work to make signif
❦ 13 juillet 2014 11:34 +0200, Jeroen Dekkers :
>> > And I've got to ask: for the couple of trivial examples that Frederick
>> > pointed out - why on earth do these even exist as libraries instead of
>> > being inlined wherever they're needed?
>>
>> Because, in node, a library is cheap and the
❦ 13 juillet 2014 08:50 +0100, Neil Williams :
>> > And I've got to ask: for the couple of trivial examples that
>> > Frederick pointed out - why on earth do these even exist as
>> > libraries instead of being inlined wherever they're needed?
>>
>> Because, in node, a library is cheap and the f
Hello,
we've got a problem with Apache that causes problems during upgrades
(e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4
changed ABIs, so that we need to ensure that dpkg properly removes
packages linking against the obsolete ABIs at upgrade time. This is the
first time
* Mike Hommey [140713 12:55]:
> > … while IMHO it's possible to safely mix openssl and libressl if we prepare
> > for that (i.e. make sure that _everything_ in libressl is only exported
> > with properly versioned symbols)
>
> Contrary to what you seem to believe, this only really works if *both
Hi Arno,
On Sonntag, 13. Juli 2014, Arno Töll wrote:
> * Ignore the problem, and refer to the manpage of aptitude without
> proper fix etc. which clearly says "THIS OPTION CAN CAUSE DATA LOSS! DO
> NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING".
seems right to me, given the alternatives you descr
Hi,
Bernhard R. Link:
> * Mike Hommey [140713 12:55]:
> > Contrary to what you seem to believe, this only really works if *both*
> > libraries have versioned symbols. Otherwise, you can end up with
> > libraries linked against the unversioned one using symbols from the
> > versioned one at run ti
Hi,
Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
> > Maybe a “gift” job for a Debian Contributor would be to put together
> > a “DD’s cheat card”, with infos about how to contact DSA, WB team,
> > etc. – nothing about the how-to of packaging, but about the orga‐
> > nisational
Joachim Breitner (2014-07-13):
> Hi,
>
> Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
> > > Maybe a “gift” job for a Debian Contributor would be to put together
> > > a “DD’s cheat card”, with infos about how to contact DSA, WB team,
> > > etc. – nothing about the how-to of pa
At Sun, 13 Jul 2014 13:17:24 +0200,
Arno Töll wrote:
> What would you do in our situation? Side note 2: We kinda expected this
> situation and added a trapdoor in Wheezy [1], but it turned out, that
> even that is not good enough to prevent havoc with --purge-unused.
It's not really ideal either,
Guus Sliepen wrote:
[...]
> The problem is that OpenSSL is much more than just an implementation of
> SSL/TLS. It is also provides a very extensive set of low-level
> cryptographic functions. There are many programs that use OpenSSL for
> the latter, not for the SSL/TLS layer. You just cannot drop
Hi Jeroen,
On 13.07.2014 15:09, Jeroen Dekkers wrote:
> It's not really ideal either, but another option would be doing an
> update in the next wheezy point release preparing this migration. For
> example moving the configuration files from apache2.2-common to
> apache2 or apache2.2-bin in wheezy
On Sun, Jul 13, 2014 at 02:02:18PM +0200, Matthias Urlichs wrote:
> Hi,
>
> Bernhard R. Link:
> > * Mike Hommey [140713 12:55]:
> > > Contrary to what you seem to believe, this only really works if *both*
> > > libraries have versioned symbols. Otherwise, you can end up with
> > > libraries linke
Package: wnpp
Severity: wishlist
Owner: deb...@jbfavre.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: python-vertica
Version : 0.2.3
Upstream Author : justin.be...@gmail.com, alex@uber.com
* URL : https://github.com/uber/vertica-python
* Licens
On 07/13/2014 09:48 PM, Mike Hommey wrote:
> On Sun, Jul 13, 2014 at 02:02:18PM +0200, Matthias Urlichs wrote:
>> Hi,
>>
>> Bernhard R. Link:
>>> * Mike Hommey [140713 12:55]:
Contrary to what you seem to believe, this only really works if *both*
libraries have versioned symbols. Otherwi
On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> for that (i.e. make sure that _everything_ in libressl is only exported
> with properly versioned symbols), again IMHO the time and effort required
PLEASE PLEASE PLEASE PLEASE PLEASE take this to the portable libressl
upstream *and make it true* for
Hi,
Mike Hommey:
> Well, it kind of is. Because those versioned symbols in openssl come
> from a debian patch, afaict. So while debian may be fine (as long as all
> build-rdeps have been rebuilt since openssl got those versioned
> symbols), other distros aren't covered, as well as binaries not
> c
On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> I am, frankly, not at all concerned with binaries not compiled on Debian
> at this point. Data point: Fedora uses a different symbol versioning
> scheme for openssl, so openssl-linked binaries from there won't run on
> Debian anyway.
>
> It's far more
Martin Zobel-Helas dixit:
>Furthermore, we will change the people.debian.org web-service such that
>only HTTPS connections will be supported (unencrypted requests will be
>redirected).
This means that requests from wget (since it switched from OpenSSL to
GnuTLS) and other utilities from slow arch
* Martin Zobel-Helas , 2014-07-13, 22:13:
The plan is to execute a final sync of home directories on 2014-JUL-26
starting at 0800Z.
http://xkcd.com/1179/
we will change the people.debian.org web-service such that only HTTPS
connections will be supported (unencrypted requests will be
redirect
Hey there.
On 07/13/2014 08:36 AM, Holger Levsen wrote:
> Hi Arno,
>
> On Sonntag, 13. Juli 2014, Arno Töll wrote:
>> * Ignore the problem, and refer to the manpage of aptitude without
>> proper fix etc. which clearly says "THIS OPTION CAN CAUSE DATA LOSS! DO
>> NOT USE IT UNLESS YOU KNOW WHAT YOU
> Meanwhile, we could try to get ever distro with a clue together, map the
> versioned symbol diffs that already exist, and see if we can come up with a
> plan to at least do downstream versioning in a compatible way.
Please, please, please speak to upstream first. It's hard work, but some
upstre
On 12/07/14 02:09, Steven Chamberlain wrote:
> [...] these warnings would be treated as errors:
>
>> > In file included from md5/md5_locl.h:98:0,
>> > from md5/md5_dgst.c:60:
>> > md5/md5_dgst.c: In function 'md5_block_data_order':
>> > ./md32_common.h:237:66: warning: right-hand
On Sun, 13 Jul 2014, Juliusz Chroboczek wrote:
> > Meanwhile, we could try to get ever distro with a clue together, map the
> > versioned symbol diffs that already exist, and see if we can come up with a
> > plan to at least do downstream versioning in a compatible way.
>
> Please, please, please
Hi Martin,
On Sun, Jul 13, 2014 at 10:13:10PM +0200, Martin Zobel-Helas wrote:
> Furthermore, we will change the people.debian.org web-service such that
> only HTTPS connections will be supported (unencrypted requests will be
> redirected).
Could you elaborate on why people.d.o will enforce https
On Sun, Jul 13, 2014 at 08:36:30PM +0200, Matthias Urlichs wrote:
> Hi,
>
> Mike Hommey:
> > Well, it kind of is. Because those versioned symbols in openssl come
> > from a debian patch, afaict. So while debian may be fine (as long as all
> > build-rdeps have been rebuilt since openssl got those v
On Sun, 2014-07-13 at 15:19:22 -0700, Steve Langasek wrote:
> On Sun, Jul 13, 2014 at 10:13:10PM +0200, Martin Zobel-Helas wrote:
> > Furthermore, we will change the people.debian.org web-service such that
> > only HTTPS connections will be supported (unencrypted requests will be
> > redirected).
>
On Mon, Jul 14, 2014 at 7:09 AM, Guillem Jover wrote:
> HSTS protects mostly from MITM (except for first connection), but I'm
> not sure if DSA is planning to add it.
HSTS is a standard part of HTTPS setup on machines run by DSA, so it
is very likely they will.
--
bye,
pabs
https://wiki.debian
38 matches
Mail list logo
