Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
❦ 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 about being ABI
> compatible, so we can easily switch from one implementation to the
> other. Just like for MariaDB / MySQL in fact (not sure if these are
> still ABI compatible though). If that's not the case, then it looses a
> lot of its purpose. As Kurt wrote, GNUTLS becomes a better alternative
> then.
It will never be ABI compatible since they have removed stuff. Anything
should be recompiled to ensure that "obsolete" functions are not used.
>> OTOH, one guy already switched his entire Linux
>> system over, so far with no visible adverse effects.
>
> And then? This gives no clue if he had to rebuild everything that
> build-depended on OpenSSL...
He did rebuild everything:
http://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/
--
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
signature.asc
Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
❦ 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 get unit
tested. That's why there are so many dependencies in this ecosystem.
Inlining is solving the wrong problem.
--
printk("MASQUERADE: No route: Rusty's brain broke!\n");
2.4.3. linux/net/ipv4/netfilter/ipt_MASQUERADE.c
signature.asc
Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
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 needed? > > Because, in node, a library is cheap and the functionality get unit > tested. That's why there are so many dependencies in this ecosystem. Unit tests do not preclude inlining. Unit tests do not preclude aggregation. It's all just about multiple blocks of code in dedicated directories inside a single source package building a single binary package from which any other package can pick and choose the bits that package needs. Just what is wrong with one binary package putting lots of js in /usr/share/javascript/$library/$version/ and using symlinks in the bigger package to pull in the files that package wants? It's more work for the maintainers but it's less work for users - which is the right way around. > Inlining is solving the wrong problem. Tiny packages are the wrong solution. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
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're needed? > > Because, in node, a library is cheap and the functionality get unit > tested. That's why there are so many dependencies in this ecosystem. You have all the extra metadata, extra git repository, extra dependency tracking, etc. no matter how 'cheap' a library is. And as far as I understand npm (correct me if I'm wrong, I don't use npm very often), it will install dependencies in a nested way, so if app1 use library1 and library2, and both those libraries use tinylibrary1, tinylibrary2 and tinylibrary3, then those 3 tiny libraries will be installed both under library1 and library2. I wouldn't really call that cheap. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wqbhy54i.wl%jer...@dekkers.ch
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 backdoor in it. > > Ok, but for whatever reason, they have an imho not as shiny track > record, as has OpenBSD. Which is no wonder, given all the revelations we > have had recently, but hey, sometimes one has to make a decision. OpenSSL was part of OpenBSD before they created the LibreSSL fork, so how isn't OpenSSL part of the OpenBSD track record? > > I think GnuTLS is actually a better alternative and wish there > > were more people developing and using it. > > But developing GnuTLS is a full-time job, and then there's the control > problem with the FSF - you are certainly aware about the problems the > original upstream ran into when he wanted to break loose from the FSF > (for a reason I have forgotten). LibreSSL is a much lower-hanging fruit, > as it is supposed to be mostly, or entirely, plug-compatible with > OpenSSL. To me, the playing field largely looks like this atm: > > * GnuTLS, with an API incompatible with OpenSSL, thus requiring huge >amounts of work to make significant use of it. It depends on how you look at it. If you see the OpenSSL API as something that isn't really well designed then other libraries not copying the API is actually a good thing. > * MatrixSSL, which once had a dubious license, and which still did not >come out too well in the SSL lib comparison I recently saw (see the >list archive), > * the now newly staffed OpenSSL project, with their mixed track >record (eg. "FIPS"), and now > * LibreSSL, which sounds much like an OpenSSL on a diet, and with some >exercise, and promising thrust behind it, but mostly simply a >drop-in. You forget one of the big problems with OpenSSL that LibreSSL doesn't fix: the license. It actually makes the mess even bigger, given that some of the GPL exceptions only talk about "the OpenSSL library" and don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in for OpenSSL we can't replace OpenSSL with LibreSSL for those projects. You also forget to list two other TLS libraries: * NSS, in my opinion the biggest downside of NSS is that it includes NSPR. This both increases the code size a lot and makes the API less nice if I remember correctly. * PolarSSL, which I really like from a technical point of view. Featurewise it is pretty complete (the only major feature it doesn't implement is DTLS AFAICS), while being one tenth the size of OpenSSL / GnuTLS: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version that is used by the Dutch government. The downsides are that it looks like it doesn't have a stable API and contributing needs copyright assignment because it is dual-licensed. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbr1y2va.wl%jer...@dekkers.ch
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 compatibility layer (though I didn't look). > 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), again IMHO the time and effort required > for _that_ would be better spent evaluating the changes both projects made > and then deciding which of the two shall be in Debian. > > Both efforts have started fairly recently, so it's kind of premature to do > that now; and while IANARTM (Release Team Member) transitioning the whole > of Debian to libressl closer to the release would not be a good idea even > if we decide it's (going to be) the better alternative. I fully agree with what's above. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c25f9b.20...@debian.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 OpenSSL compat layer. It is still very limited. The GnuTLS API is a better choice if you are using GnuTLS. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lv3a9b-8ts@argenau.downhill.at.eu.org
DD's cheat card (was Re: Bug#754416: makefs: FTBFS on mips: Must set MACHINE_ARCH to one of mipseb or mipsel)
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 to find the eMail address *and* the format to use for the message. Six minutes of both duckduckgoïng and searching and looking through devref. It turns out that it was in devref, but ‘/’-searching in Lynx did not find it with the right keywords. So why is this so hard? I imagine DDs very rarely need to request wanna-build state changes… and when they do, the information should be easier to find. 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 things in Debian. Maybe also an excerpt of the most relevant things from control@b.d.o, things like that, things which a DD (or even DM) may need occasionally. Something to bookmark. Just a thought. bye, //mirabilos -- 21:41⎜«Tonnerre:#nosec» Do at least one thing every day which makes ⎜inspirational quotes lovers sad -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1407131047390@herc.mirbsd.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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
> > other.
>
> That depends. If the ABI in question includes calls or constants which are
> the security equivalent of gets() or scanf("%s") or …, then no.
>
> > 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 …
>
> > Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but not
> > have the choice between the 2, otherwise, that's a recipe for disaster.
> >
> Well …
>
> > Please don't upload LibreSSL to Sid *ever*, unless we collectively
> > decide that we are switching away from OpenSSL (and for which a
> > discussion would have to start).
> >
> … 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*
libraries have versioned symbols. Otherwise, you can end up with
libraries linked against the unversioned one using symbols from the
versioned one at run time when both are loaded in the same address
space.
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140713105459.ga16...@glandium.org
Re: DD's cheat card (was Re: Bug#754416: makefs: FTBFS on mips: Must set MACHINE_ARCH to one of mipseb or mipsel)
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 mistake of mine. But it took me about > six minutes to find the eMail address *and* the format to use for > the message. Six minutes of both duckduckgoïng and searching and > looking through devref. > > It turns out that it was in devref, but ‘/’-searching in Lynx did > not find it with the right keywords. > > So why is this so hard? I imagine DDs very rarely need to request > wanna-build state changes… and when they do, the information should > be easier to find. > > 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 things in Debian. Maybe also an excerpt of the most > relevant things from control@b.d.o, things like that, things which > a DD (or even DM) may need occasionally. Something to bookmark. https://www.debian.org/intro/organization Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 significant use of it. > > It depends on how you look at it. If you see the OpenSSL API as > something that isn't really well designed then other libraries not > copying the API is actually a good thing. 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 in GnuTLS, MatrixSSL or PolarSSL for those. Some of the alternatives to OpenSSL come with the essential cryptographic primitves to support SSL/TLS built-in, others rely on external libraries to do that. For example, GnuTLS currently depends on Nettle. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
❦ 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 functionality get unit >> tested. That's why there are so many dependencies in this ecosystem. > > You have all the extra metadata, extra git repository, extra > dependency tracking, etc. no matter how 'cheap' a library is. It still makes the library cheap. Those extra stuff are why the library is done in the first place. They allow people to find simple stuff without reimplementing it (usually with additional bugs). That's exacerbated by the fact that the standard library is inexistent with javascript and that the one that comes with node is quite small. Looking at the stats of this trivial library: https://www.npmjs.org/package/ms I see it is quite popular and used by many (101) projects. That's projects finding the library useful enough to not inline it. > And as far as I understand npm (correct me if I'm wrong, I don't use > npm very often), it will install dependencies in a nested way, so if > app1 use library1 and library2, and both those libraries use > tinylibrary1, tinylibrary2 and tinylibrary3, then those 3 tiny > libraries will be installed both under library1 and library2. I > wouldn't really call that cheap. You are right. That's their way to not have to really manage versioning. But that's the same cost when inlining. And that's irrelevant in the Debian case since we don't nest. -- Treat end of file conditions in a uniform manner. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
❦ 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 functionality get unit >> tested. That's why there are so many dependencies in this ecosystem. > > Unit tests do not preclude inlining. > Unit tests do not preclude aggregation. > > It's all just about multiple blocks of code in dedicated directories > inside a single source package building a single binary package from > which any other package can pick and choose the bits that package needs. > > Just what is wrong with one binary package putting lots of js > in /usr/share/javascript/$library/$version/ and using symlinks in the > bigger package to pull in the files that package wants? Aggregation is not inlining. I was talking about inlining. I have no opinion about aggregation. -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ 2.4.3 linux/net/core/netfilter.c signature.asc Description: PGP signature
Solutions for the Apache upgrade hell
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 this happened since Debian Etch, so this brings a problem to the spotlight, that hasn't been one for a long time. To summarize the bug reports: The problem is, that Apache package maintainers at that time decided, that third party modules shall depend on apache2.2-common, by guaranteeing ABIs remain stable as long as the package name does not change. This is, so far policy compliant. However, by now ABIs did change and we were forced to rename the package (we did so, by providing a virtual API package third parties must depend on. At time of writing this is apache2-api-20120211). Unfortunately, apache2.2-common also contains conffiles and configuration file handling in postinst/postrm ... I spent a lot of time to properly transition to a new state with conffiles/configuration separated from ABI handling, and this works well enough for regular updates by now. Unfortunately it turns out, that /a lot/ of people use "aptitude --purge-unused safe-upgrade", or the apt equivalent "apt-get dist-upgrade --purge" which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. Those people end up with effects as described in the bugs outlined above, for example with incomplete installations because our maintainer scripts had no chance to properly detect the state of the /etc/apache2 directory before the upgrade. This gives us three possibilities which all have unwanted side effects (unless you come up with an idea that all of us makes happy). I'm writing to this list in hope that someone has a very smart idea to make everyone happy, or express your support for either alternative to give us some insights what people think would be the best alternative. * 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". The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? * Add a apache2.2-commmon transitional package. This gives us a chance to inspect /etc/apache2 in spite of --purge-unused and properly transition to Apache 2.4. HOWEVER, this has the nasty side effect that modules ABIs are considered compatible as far as dpkg is concerned. Therefore, old module packages aren't forced to be removed and this breaks at runtime when people try to start their upgraded web server with incompatible modules. As a workaround we could add a versioned "Breaks" for all modules in Wheezy (~ 75) in the apache2.2-common transitional package, and in addition for packages that existed in Squeeze or Etch only (no, really). That said, this still won't help for third party modules outside Debian which people might use (and to my best knowledge, they do a lot) and it's generally problematic in view of the policy with respect to library packaging (even though we're not a library strictly speaking) * Treat the upgrade as new install in our maintainer scripts when --purge-unused was used (side question: Any idea how to reliably and properly detect that case, as the binary package name changed and it's well possible that in Wheezy apache2.2-common is installed, but not apache2 because of weird(tm) packaging)? This would not preserve user's choices in regard of enabled/disabled modules and thus be a borderline policy violation, too. 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. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.2-common.postrm;h=bbe9f740b81cf8af64412f7ba6aace119dd159ad;hb=refs/heads/wheezy#l5 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
* 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* > libraries have versioned symbols. Otherwise, you can end up with > libraries linked against the unversioned one using symbols from the > versioned one at run time when both are loaded in the same address > space. Actually, "both having versioned symbols" is not enough. It is either "both must always have had versioned symbols" or "both must have versioned symbols now and every binary linked against either must have been built (or rebuilt) after the symbols got versioned". Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014071333.ga6...@client.brlink.eu
Re: Solutions for the Apache upgrade hell
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 describe. I've never used "upgrade --purge" _in one step_ and I don't think it's a particularily smart idea at all. But if people want to shoot themselves in the feet, we should tell them that it might hurt, but then... let them. Same for not reading release notes, if someone wants to act stupid... ;-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 time when both are loaded in the same address > > space. > > Actually, "both having versioned symbols" is not enough. > It is either "both must always have had versioned symbols" or > "both must have versioned symbols now and every binary linked against > either must have been built (or rebuilt) after the symbols got > versioned". > Bah. Thanks for the correction. However, it seems that the current OpenSSL package _does_ have fully-versioned symbols, at least if I understand "objdump -T" correctly. So the situation may not be as dire as this thread suggests. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713120217.gb15...@smurf.noris.de
Re: DD's cheat card (was Re: Bug#754416: makefs: FTBFS on mips: Must set MACHINE_ARCH to one of mipseb or mipsel)
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 things in Debian. Maybe also an excerpt of the most > > relevant things from control@b.d.o, things like that, things which > > a DD (or even DM) may need occasionally. Something to bookmark. > > https://www.debian.org/intro/organization not really helpful. It links to https://buildd.debian.org/ from where no information about how to query for rebuilds can be found. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: DD's cheat card (was Re: Bug#754416: makefs: FTBFS on mips: Must set MACHINE_ARCH to one of mipseb or mipsel)
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 packaging, but about the orga‐ > > > nisational things in Debian. Maybe also an excerpt of the most > > > relevant things from control@b.d.o, things like that, things which > > > a DD (or even DM) may need occasionally. Something to bookmark. > > > > https://www.debian.org/intro/organization > > not really helpful. It links to > https://buildd.debian.org/ > from where no information about how to query for rebuilds can be found. I'm not sure what's wrong with the following, quoted from the said page: | Autobuilding infrastructure — | | Wanna-build team — | […] | Buildd administration — @buildd.debian.org Mraw, KiBi. signature.asc Description: Digital signature
Re: Solutions for the Apache upgrade hell
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, 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 shouldn't cause any problem and after the files have been moved apache2.2-common can be safely purged during upgrade. Moving them to apache2 package would mean you won't have to move them again in the upgrade to apache 2.4, but it would create a new and circular dependency of apache2.2-common on apache2. Given that apache2.2-common already depends on apache2.2-bin and there exists a transitional package in jessie it might be a better candidate. Then you would have to move it again in the jessie package, but I'm afraid there aren't any easy solutions. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r41pxv50.wl%jer...@dekkers.ch
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 in GnuTLS, > MatrixSSL or PolarSSL for those. > Some of the alternatives to OpenSSL come with the essential > cryptographic primitves to support SSL/TLS built-in, others rely on > external libraries to do that. For example, GnuTLS currently depends > on Nettle. Hello, However, gnutls exposes some cryptographic primitives through its crypto API, so it is not necessary to directly use nettle (or gcrypt) if the exposed subset is sufficient. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/l3da9b-jod@argenau.downhill.at.eu.org
Re: Solutions for the Apache upgrade hell
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 shouldn't cause any problem and > after the files have been moved apache2.2-common can be safely purged > during upgrade. thanks for bringing this up. We had discussed this a while back, but I forgot to list it in the provided alternative choices. > Moving them to apache2 package would mean you won't have to move them > again in the upgrade to apache 2.4, but it would create a new and > circular dependency of apache2.2-common on apache2. Given that > apache2.2-common already depends on apache2.2-bin and there exists a > transitional package in jessie it might be a better candidate. Then > you would have to move it again in the jessie package, but I'm afraid > there aren't any easy solutions. Pretending the Release Team would allow us to do that (Frankly, I wouldn't dare to ask :p) thee are two caveats with that approach that would make it very hard and complicated because our historic heritage dating back to Etch days again. It's well possible, that people have apache2.2-common installed, but not apache2. In Wheezy and earlier "apache2" is very much an empty pseudo package nothing depends on. Unless the user did "apt-get install apache2" they won't end up with it as a dependency. This is commonly the case if you did "apt-get install php5" for example. We cannot move conffiles to apache2.2-bin either, because Gnome for example depends on that package (don't ask) and it does it's own configuration completely detached from Debian packaging and Debian configuration. Therefore, people that don't use Apache on their own have that package installed, too. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 linked against the unversioned one using symbols from the > > > versioned one at run time when both are loaded in the same address > > > space. > > > > Actually, "both having versioned symbols" is not enough. > > It is either "both must always have had versioned symbols" or > > "both must have versioned symbols now and every binary linked against > > either must have been built (or rebuilt) after the symbols got > > versioned". > > > Bah. Thanks for the correction. > > However, it seems that the current OpenSSL package _does_ have > fully-versioned symbols, at least if I understand "objdump -T" > correctly. > > So the situation may not be as dire as this thread suggests. 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 compiled on debian. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713134837.ga18...@glandium.org
Bug#754703: ITP: python-vertica -- native Python client for the Vertica database
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 * License : MIT Programming Lang: Python Description : native Python client for the Vertica database HP Vertica is a commercial column-oriented database. This package provides all the source, examples and documentation to easily connect to and interact with Vertica. I already use, and maintain, the package at work. I will take care of the packaging and maintain the package. I got help from Debian Developers Vincent Bernat and Sylvestre Ledru to prepare the package. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJTwpMVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RTg0NUJBMjMwQ0I0RDQ0ODkwNjk4NDdC NERENTM2QUNGN0Q4NzM3AAoJELTdU2rPfYc3FLcP/RiET5ucHETzNwz9ZMrHXNcj hSqOQ9nyiqmPslWNhk6JekVoO4S+li1tHGuOIRc3Db1qXLIDZdSH0j3tjZUG/2+I 7tlZIkmpJSI6Z2AfX3ujnluEXMB7dLmwcvhrMy8sAtj2MHAb2eF+zK+hnOr4wbMh pBaKIQqwihzch/3QAiymmt4QJVQSclsQFVYFC8PZG4E3AGDdo5kA1iOSYAgnW3gy xdHqj6/mqOa4nyHK61IVj1kW2A2TCfob6RtfpMyOXXgSeJ8I94Rv8RP0Aiqdfl8G 6OLjOjGY8ds76WFIzT86xp326N2+mvq/W5/B4/NydWx8fPfNGVEGegSZG6KJW43V +mSwQ6VITO9isD/nyDZrQvhg1tTZNO9iA/H+ZatOJYtGldc079UXj7Kr37OgOP8E O3mgdbt9rxRl+uaTsfCitjpvUiaV6nBWRccs1KNikQwCZ0Bkgv5JlvY8xMaWn+DH GxLsXHWkaLiJKBHemS57fm2Q/HhG4JL+6SPnDzjCJ4dj2+/EYXSQlv4lUxkBt30t p9oG74HZwdl1ZoL5DbqrfaUKpk4FCLSKxkyBFXA18SNbdMZ5Oh4xXOWJVN3LALuj DCRbavDLRN+1RXA7sCcm5xI8O35K4X5r1TQzg7FVeqLr5kon8JmAV/hOjXJh4T54 /7gh4GSRntGRNuFpwFT0 =MlnH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713140925.2365.87477.report...@jbfavre.lan
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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. Otherwise, you can end up with libraries linked against the unversioned one using symbols from the versioned one at run time when both are loaded in the same address space. >>> >>> Actually, "both having versioned symbols" is not enough. >>> It is either "both must always have had versioned symbols" or >>> "both must have versioned symbols now and every binary linked against >>> either must have been built (or rebuilt) after the symbols got >>> versioned". >>> >> Bah. Thanks for the correction. >> >> However, it seems that the current OpenSSL package _does_ have >> fully-versioned symbols, at least if I understand "objdump -T" >> correctly. >> >> So the situation may not be as dire as this thread suggests. > > 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 > compiled on debian. Why should we care about other distros? Do they have an impact on us? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c29896.9050...@debian.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 the Linux targets. Now. Before people start shipping for real non-versioned-symbols versions of libressl everywhere and third party closed-source applications pick on that. And please use a libressl-specific symbol version (LIBRESSLxy, for example). > that now; and while IANARTM (Release Team Member) transitioning the whole > of Debian to libressl closer to the release would not be a good idea even > if we decide it's (going to be) the better alternative. Indeed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713171629.gb23...@khazad-dum.debian.net
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 > compiled on debian. > 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 imperative to educate upstream (in general, not just openssl – but them in particular) about the fact that adding versioning to their libraries is a Very Good Idea which will save them (and, more to the point, anybody using their code) a whole lot of hassle – as well as potential security holes – if/when their ABI changes. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713183630.gf3...@smurf.noris.de
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 imperative to educate upstream (in general, not just openssl > – but them in particular) about the fact that adding versioning to their > libraries is a Very Good Idea which will save them (and, more to the point, > anybody using their code) a whole lot of hassle – as well as potential > security holes – if/when their ABI changes. 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. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713200739.ga1...@khazad-dum.debian.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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 architectures (such as m68k or avr32) to people.d.o will timeout. Take it as a heads-up to maybe move stuff elsewhere, if it needs http (e.g. APT repos work well via http since they use PGP for signatures). bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour” -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1407132021060.32...@herc.mirbsd.org
Re: people.debian.org will move from ravel to paradis and become HTTPS only
* 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 redirected). This is great news. Thanks! :-) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713203139.ga9...@jwilk.net
Re: Solutions for the Apache upgrade hell
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 ARE DOING". > seems right to me, given the alternatives you describe. > > I've never used "upgrade --purge" _in one step_ and I don't think it's a > particularily smart idea at all. But if people want to shoot themselves in > the > feet, we should tell them that it might hurt, but then... let them. > > Same for not reading release notes, if someone wants to act stupid... ;-) I agree in every single aspect with Holger. An "upgrade --purge" sounds to me like: "Upgrade and start with fresh configuration". I usually proceed with "dist-upgrade", then "autoremove --purge" to keep things neat. Again, should a release note poping up right in front of your eyes be ignored, there's not much to prevent you from damaging your system if you don't really care about it. Not really trying to act rude here (and I'm sorry if it seems so, just can't figure out another way to put it simple), but package management systems are, IMHO, intended to facilitate the access and installation of packages which are part of the distro/release while preventing us from facing dependancy-hell-like situations, they're not intended to be fool-proof, as it requires administrative privileges, therefore expecting that you *really* know what you're doing. Cheers, Fabiano. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c2edbe.2060...@itgen.com.br
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
> 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 upstreams can be convinced to do the right thing. -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ion1gflu.wl-...@pps.univ-paris-diderot.fr
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 operand of comma expression >> > has no effect [-Wunused-value] >> > # define HOST_c2l(c,l) ((l)=*((const unsigned int *)(c)), (c)+=4, l) >> > ^ A new upstream release LibreSSL 2.0.1 already addressed that: basically stop using -Werror in the portable library because many compilers have warnings that OpenBSD's compiler does not, and I guess they did not think the warnings legitimate or worth the effort of 'fixing' right now. This new version brings in many small changes from the still-ongoing cleanup. ABI versions bumped to libcrypto 30.0.0 and libssl 27.0.0. AFAICT only private_RC4_set_key was removed, and ssl_version_string added to the respective libraries' exported symbols. Am I right in thinking Debian would not bump its own SONAME if there were unimportant ABI changes, like these seem to be? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c2ef58.4050...@pyro.eu.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 speak to upstream first. It's hard work, but some > upstreams can be convinced to do the right thing. Yes. Getting upstream in the loop has to be part of any plan re. versioning symbols. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713210621.ga3...@khazad-dum.debian.net
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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? If http connections are still allowed, this doesn't provide any protection from a MITM attack for most users; and the contents of people.d.o are not generally security sensitive. Is this part of a broader effort by DSA to increase use of https by default as a deterrent to large-scale traffic sniffing? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
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 versioned > > symbols), other distros aren't covered, as well as binaries not > > compiled on debian. > > > 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 imperative to educate upstream (in general, not just openssl > - but them in particular) about the fact that adding versioning to their > libraries is a Very Good Idea which will save them (and, more to the point, > anybody using their code) a whole lot of hassle - as well as potential > security holes - if/when their ABI changes. I plan to try and get them to use symbol versioning, at least on those platforms that support it. This will probably be just like the patch currently in Debian. I don't plan to add multiple versions of a symbol to try and keep the same soname since that probably won't work on all platforms. We also plan to reduce the risk of breaking the ABI. Now a lot of structs are public and we would like to make them private and provide functions for those things that people want to access. This will all probably take some time. PS: If you use dlopen()/dlsym() to load functions, symbol versioning doesn't help unless you use dlvsym() which is a glibc extension. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713224303.ga20...@roeckx.be
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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). > > […] If http > connections are still allowed, this doesn't provide any protection from a > MITM attack for most users; and the contents of people.d.o are not generally > security sensitive. HSTS protects mostly from MITM (except for first connection), but I'm not sure if DSA is planning to add it. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713230911.ga30...@gaara.hadrons.org
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6fi2q4x1lmqvdw7nphr0tbuxprswjhfgrqi9tgqzn5...@mail.gmail.com
