Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 05:31:26PM +0100, Thomas Jollans wrote: > stuff. If I needed something more production-ready, I'd use testing > because you have (almost) garantee that the software will work and you > will have security updates, too. (But not in the same quality as Unfortunately, testing does not guarantee security updates. Sure, one day the updates will promote from unstable to testing. But this can take a long time, if, for example, some dependencies block the new version from testing. This may change with a testing-security upload queue. Jan
Re: New stable version after Sarge
On Thu, Jan 06, 2005 at 09:51:21AM +0100, Marc Haber wrote: > That would leave testing users who happen to have such a package > installed alone because they wouldn't notice their package vanishing > from the mirrors, continuing to use a potentially vulnerable package. Good point. But that problem can be solved by some program checking that all installed packages are actually available from the selected distribution(s). That could be integrated into apt (e.g. apt-get upgrade warning about packaged without a current installation canditate, or where the most recent version from the archives is older than the installed one), or it could be a separate tool. Perhaps it can even be done with existing tools? Jan
Re: The sarge release disaster - some thoughts
On Tue, Mar 15, 2005 at 05:39:37PM +0100, Frank Lichtenheld wrote: > So where is the lack of communication you detected? Well, at least to me it's completely unclear why it took so long to address the points you mentioned (t-s, d-i). There are probably very good reasons, and people did work hard to address the problems ASAP, but with the information publicly available, one can only guess about that. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible compromise on releasing architectures
On Thu, Mar 24, 2005 at 12:59:19AM -0800, Blars Blarson wrote: > Release candidate architecture: > > * testing managed by port release manager(s) > * testing consists of packages that built on the candidate and > are in release architecture testing with the same version Please specify what applies to sources and what to binaries. As I understand your proposal, one would need architecture specific source repositories (as different architectures may have different versions in testing). Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First call for votes for the Lenny release GR
On Thu, Dec 18, 2008 at 04:45:02PM +1100, Russell Coker wrote: > It seems that the grass-roots support for doing something quite different to > the current vote includes me, Brian, and quite a few bloggers on Planet > Debian. I don't like the current vote either and wouldn't mind if it was canceled. My suggestion is to do a very simple vote first, with only two choices: a) continue with the release process and don't wait for further GRs Of course this means, effectively, that we do trust the release team and other developers involved in the release process b) wait with the lenny release until we made decisions on the open issues This means that we don't want do be hasty, take our time to agree what the open issues are, how they could be resolved and what further GRs are necessary to finally decide on these matters. The third option, further discussion, could be included on the ballot for completeness, but as it is roughly equivalent to "I don't want to delay lenny but I don't want to release it in it's current state either", it's only for people who really can't decide what they want :-) IMHO we have to bite the bullet: Either we release lenny without agreeing on the DFSG issues first, or we delay lenny. As the vote suggested above is only sensible if lenny isn't delayed by the vote itself, it would be good to start it ASAP and do it with a shortened voting period. Jan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#435693: ITP: qca2-plugin-ossl -- OpenSSL plugin for QCA2
Package: wnpp Severity: wishlist Owner: Jan Niehusmann <[EMAIL PROTECTED]> * Package name: qca2-plugin-ossl Version : 0.1~20070706 Upstream Author : Justin Karneges <[EMAIL PROTECTED]>, Brad Hards <[EMAIL PROTECTED]> * URL : http://delta.affinix.com/qca/ http://delta.affinix.com/download/qca/2.0/beta7/ * License : LGPL Programming Lang: C++ Description : OpenSSL plugin for QCA2 This plugin provides features based on OpenSSL. It implements: * Hashing - SHA1, SHA0, RIPEMD160, MD2, MD4, MD5 * Hashing - SHA224, SHA256, SHA384 and SHA512 (for openssl 0.9.8) * Block Ciphers * Keyed Hash Message Authentication Code (HMAC), using SHA1, MD5, RIPEMD160 * Public keys - RSA, DSA, Diffie-Hellman * PKCS#12 * SSL/TLS * CMS (for S/MIME) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#223469: ITP: qca -- The Qt Cryptographic Architecture (QCA), cryptographic algorithmns for Qt programs
Package: wnpp Severity: wishlist * Package name: qca Version : not yet released, currently CVS only Upstream Author : Justin Karneges <[EMAIL PROTECTED]> * URL : http://psi.affinix.com/ * License : LGPL Description : The Qt Cryptographic Architecture (QCA) This library provides an easy Qt-compatible API for the following features: SSL/TLS X509 SASL RSA Hashing (SHA1, MD5) Ciphers (BlowFish, 3DES, AES) Functionality is supplied via plugins. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux sirith 2.4.22 #1 Sat Aug 30 16:40:19 CEST 2003 i686 Locale: LANG=C, [EMAIL PROTECTED] signature.asc Description: Digital signature
Security updates for sarge? (was: Ubuntu discussion at planet.debian.org)
On Fri, Oct 22, 2004 at 10:20:51AM +0200, Jérôme Marant wrote: > Debian developers, on the contrary, run unstable and rarely run > testing, which means that they don't really know about the shape > of what they release. I would immediately upgrade at least one, probably more, woody machines to sarge if there was a working security update system. And I guess I'm not the only one. Question to the security team: What's holding back security support for sarge? (This is not a complaint - I'm just curious) Jan
Re: Fwd: Please confirm your message
On Sun, Dec 01, 2002 at 08:43:06PM +0100, Russell Coker wrote: > When you have a very small number of people doing something totally contrary > to what everyone else on the Internet is doing, and expecting that everyone > else should go out of their way to accomodate them, then you don't need to do > any research into who they are. See it that way: The problem of spam unfortunately is not solved, yet. There are several approaches to limit the amount of spam, and none of them is perfect. So, some research is necessary to find better ways of limiting spam. And the best way to evaluate some spam filter is to use it. Of course, that may annoy people, and these people should speak up (because that adds important information to the evaluation process - a spam filtering scheme which annoys people too much will not work in the long run). But please don't take it personal. > It is not suitable for individual email addresses. Time will tell. I fear that some day, the only way to use email productively is to block all email with invalid sender adresses. And I don't know a way do valdiate a (not yet known) address but to try it and send a reply. If you combine that with some autoresponders on both ends, no human interaction would be needed, so annoyance should go down. Jan
Re: Fwd: Please confirm your message
On Mon, Dec 02, 2002 at 04:58:48PM +0100, Russell Coker wrote: > On Mon, 2 Dec 2002 16:39, Jan Niehusmann wrote: > > Time will tell. I fear that some day, the only way to use email > > productively is to block all email with invalid sender adresses. And I > If an auto-responder can handle such messages then spammers will just > use such auto-responders and therefore the spam filter will be almost > useless. You are missing the point: That scheme doesn't directly block spam, it only assures that a mail has a valid Reply-To:-address. Which may (or may not) stop spam. Time will tell. > Also there's the issue of two people having such filters trying to > communicate with each other. Of course such programs need careful design to prevent loops. I don't say this is the only solution, I don't even claim it solves the spam problem at all. But I think it's a sensible experiment. After all, it may work. Jan
Re: Fwd: Please confirm your message
On Mon, Dec 02, 2002 at 08:18:46AM -0800, Stephen Zander wrote: > The above is based on the false premise that those who send spam are > incapable of sending it with (forged) real email addresses. They > already have lots of them to choose from. But if they send the spam with a forged email address, the confirmation request won't be answered. (Which needs to be considered when designing a confirmation auto-responder: It may only confirm messages which were actually sent from that account) Jan PS: I think we are getting off-topic. I am interested in your opinion, but please consider sending it by private email.
Re: Bug#171693: ITP: wondershaper -- a script to set up QoS, mainly for home users
On Wed, Dec 04, 2002 at 02:25:43PM +0100, Joerg Friedrich wrote: > and the other htb-based. cbq is no longer developped, but tc from > iproute does not support htb. Well, according to the changelog, tc does support htb, but it's probably based on htb2 and 2.4.20 contains htb3, which seems to be incompatible. But for people using htb2, the wondershaper script could be useful now, so I think it'd be fine to upload it now. Jan
Re: Bug#171693: ITP: wondershaper -- a script to set up QoS, mainly for home users
I'd say a package wich only works with a recent kernel version is not a problem. Add a note to the description, and let the program detect availability of the necessary features at runtime, with a meaningfull error message if the feature is missing. By the way, the iproute package just got updated: iproute (20010824-9) unstable; urgency=medium * Added patch for HTB v3.6 to be able to work with kernel 2.4.20 (from http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz) (closes: Bug#147550, Bug#167149, Bug#167597, Bug#171277) -- Juan Cespedes <[EMAIL PROTECTED]> Thu, 05 Dec 2002 13:44:10 +0100 Jan
Re: plagiarism of reiserfs by Debian
On Sun, Apr 20, 2003 at 06:19:28PM -0400, Glenn Maynard wrote: > Remember, the issue here isn't whether there's good reason to remove the > Reiser message, but whether we're allowed to (apparently not) and > whether not being allowed to do so is DFSG-free. Even if we were happy > with simply putting it back in, it still can't go in main if it's not free. Are you sure about that? I didn't read all the messages in this thread, but from the ones I read, I get the impression that Hans is not trying to say that debian does something illegal. I read phrases like rude, impolite, and ingrateful, but not illegal. He did talk about 'violation of copyright' in his first mail, but reading his second mail, I'm quite sure he doesn't really care about legal positions, but about fairness. I think debian should respect the authors' wishes, even if we would be allowed not to do so. This is not about DFSG-freeness, it's just nice behaviour. And of course, now that the topic is being discussed, it's of course ok to ask Hans if the messages can be turned of under certain circumstances, if that improves the usefulness of the software to the users. Jan
emu10k1-mixer?
Is there a mixer available that supports the advanced mixing features of the emu10k1 chip (found on Soundblaster Live) ? The only one I know is 'dm', a little but very usefull command line tool. As it's not yet in debian, I will ITP it if there are no alternatives. There is another point I'm not sure about: dm is part of the emu10k1-driver-package from http://opensource.creative.com/. This package contains some other tools. Although I don't use these tools, and I don't know much about them, I think they should be packaged together with dm in a package called emu10k1-utils or something like that. On the other hand, as I don't even know how to use these tools, it's not clear to me if they are working. As Soundblaster Live is a fairly common soundcard, I wonder why there are so few tools to use it's features. Being able to route sound from any of it's inputs to any output independently is a great thing. And having a programmable DSP should be even greater to people who need it. Jan -- OpenPGP-signierte bzw. -verschlüsselte Mail erwünscht EMail-Key: 1024D/F12DA065 (=> Keyserver oder auf Anfrage)
Re: mutt-1.3.24-3 complains of read-only /var/mail/foo
On Wed, Jan 02, 2002 at 11:00:58AM -0900, Christopher S. Swingley wrote: > > A quick search of the debian-devel archive didn't turn up > > anything about this, but I might have goofed the search. > > Anyway, mutt-1.3.24-2 works well enough for me, but 1.3.24-3 > > won't let me modify /var/mail/foo. > > # chown root:mail /usr/bin/mutt_dotlock > # chmod 2755 /usr/bin/mutt_dotlock > > $ ls -l /usr/bin/mutt_dotlock > -rwxr-sr-x1 root mail /usr/bin/mutt_dotlock This bug is fixed in mutt-1.3.25-1, and besides this minor glitch, it's important to upgrade to 1.3.25 because it fixes a rather serious security hole. Jan
Release.gpg
Hi! Is there a reason why the Release.gpg files for testing and unstable are empty? I'm using the Wichert's script to check the integrity of the local mirror, but at the moment this is not possible because auf the missing signature. Jan
Re: Release.gpg
On Mon, Jan 14, 2002 at 03:30:45PM +0100, Jan Niehusmann wrote: > I'm using the Wichert's script to check the integrity of the local Sorry, wrong attribution - of course, the script is written by Anthony Towns.
Re: Release.gpg
On Mon, Jan 14, 2002 at 05:51:39PM +0100, Martin Schulze wrote: > Jan Niehusmann wrote: > > Is there a reason why the Release.gpg files for testing and unstable are > > empty? > > A bug on your end of the pipe? > > auric!joey(pts/0):/org/ftp.debian.org/incoming> l `locate Release.gpg` [...] > -rw-r--r--1 ajt debadmin 480 Jan 14 10:28 > /org/ftp.debian.org/ftp/dists/woody/Release.gpg [...] But: bash-2.05a$ ncftp ftp.debian.org NcFTP 3.1.1 (Dec 23, 2001) by Mike Gleason ([EMAIL PROTECTED]). Connecting to 128.101.36.192... saens.debian.org FTP server (vsftpd) Logging in... Login successful. Have fun. Sorry, I don't do help. Logged in to ftp.debian.org. Current remote directory is /debian/dists/testing. ncftp /debian/dists/testing > ls -l *.gpg -rw-r--r-- 77 1176 11760 Jan 13 22:53 Release.gpg This does look empty... but perhaps the problem has already been fixed and the files only needs to propagate to the mirrors. Jan
NEW packages stalled?
Hi! Can anybody tell me why the psi package in queue/new doesn't get processed? I made an upload which only changed 'non-US' to 'net' nearly three weeks ago. (I added another upload with new features last week) If there is anything wrong with this package, please tell me, so I can correct it. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW packages stalled?
On Mon, Apr 15, 2002 at 09:29:10PM +1000, Anthony Towns wrote: > ] Build-Depends: debhelper (>> 3.0.0), tmake, libqt3-mt-dev, libssl-dev > ^^ > OpenSSL can't be used with GPL licensed software. The psi binary package doesn't contain openssl code. The only thing needed at compile time is the ssl.h header file, and the created binary works perfectly well without openssl. It is not linked against openssl. So I don't see how this conflicts with GPL. If you have an convincing argument, I am sure the author of psi will add an exception clause to his license, as he did for qt. (SSL support is included in the sources and binaries distributed by the upstream author, as well) Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Allow encfs into jessie?
Hi, due to bug #736066, encfs was removed from jessie. I'd think it would be better to allow encfs into jessie for the following reasons: The bug report is about security issues, but these are not security issues of the software (as in: you can somehow hack into the computer wich is running the software), but of the encryption algorithms used. So it can be compared to a package implementing md5: Yes, it's known that md5 is not secure any more, but that's not a reason to remove all packages implementing md5 from debian. One could argue that encfs shouldn't be used any longer to encrypt files, and therefore encfs is just not useful and can be removed. But many users will have legacy installations using encfs encrypted file systems, and will be surprised that they can't access them any more from jessie. So removing encfs will cause major inconveniences to some of our users. Therefore, I propose that encfs should be allowed into jessie. (What would be the right way to do that? Lower the severtiy of the bug? Add a jessie-ignore tag?) To notify users about the potential security issue, a NEWS file could be added, or one could add a warning to the output of the encfs command. Regards, Jan -- 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/20140911101208.ga17...@x61s.reliablesolutions.de
Re: Allow encfs into jessie?
Hi Holger, On Thu, Sep 11, 2014 at 06:42:32PM +0200, Holger Levsen wrote: > I (probably too briefly) skimmed though the bug report, but couldn't find a > usecase where an encrypted filestem container with broken crypto could be > useful. Could you elaborate, please? As far as I understand the EncFS Security Audit, encfs is not using 'broken crypto'. The conclusion of the audit states it quite clearly: "EncFS is probably safe as long as the adversary only gets one copy of the ciphertext and nothing more. EncFS is not safe if the adversary has the opportunity to see two or more snapshots of the ciphertext at different times. EncFS attempts to protect files from malicious modification, but there are serious problems with this feature." (from https://defuse.ca/audits/encfs.htm) A common use case for disk encryption is to protect a lost or stolen laptop. And the adversary is not some powerful agency, but a curious person browsing through the hard disk before formatting it. I see no reason to assume that encfs is not good enough for that use case, at the moment. Of course, the crypto should be improved ASAP, as attacks to crypto only get better. Regards, Jan -- 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/20140912114636.ga2...@jannic.reliablesolutions.de
Bug#975630: ITP: condure -- HTTP/WebSocket connection manager
Package: wnpp Severity: wishlist Owner: Jan Niehusmann * Package name: condure Version : 1.1.0 Upstream Author : Justin Karneges * URL : https://github.com/fanout/condure/ * License : Apache-2.0 Programming Lang: Rust Description : HTTP/WebSocket connection manager Condure is a service that manages network connections on behalf of server applications, in order to allow controlling the connections from multiple processes. Applications communicate with Condure over ZeroMQ. Condure can only manage connections for protocols it knows about. Currently this is HTTP/1 and WebSockets. See Supported protocols. The project was inspired by Mongrel2. The existing package pushpin supports condure as an alternative to mongrel2, and it looks like upstream is slowly migrating from mongrel2 to condure. As a rust software, this will be packaged as part of the debian-rust team.
Re: OpenSSL 1.1.0
Hi, On Fri, Nov 04, 2016 at 11:58:44PM +0200, Adrian Bunk wrote: > You could enforce that no Qt-using package uses the wrong OpenSSL by > adding libssl1.0-dev dependencies to libqt4-dev and qtbase5-dev. How can I handle the case of a package which uses both qt and curl? The latter already switched to OpenSSL 1.1. Jan
Re: OpenSSL 1.1.0
Hi,
(Cc to Alessandro because this causes issues with libcurl)
On Wed, Nov 02, 2016 at 09:15:13PM +0100, Kurt Roeckx wrote:
> I don't think having libssl1-1-dev vs libssl1.0-dev is going to
> make much differences in the end. The build conflicts will always
> have to be sorted out.
Well I think it makes a difference:
With libssl-dev silently switching to OpenSSL 1.1, packages get
recompiled with the new version, but the maintainers may be unaware that
this causes compatibility issues.
I have a concrete example:
It seems like the package zurl is broken by libcurl3 being linked with
OpenSSL 1.1.
This means the binary package zurl 1.7.0-1 works fine with libcurl3
7.50.1-1, but fails to connect to https URLs when libcurl3 is upgraded
to 7.51.0-1.
(It also works with curl 7.51.0-1 recompiled with OpenSSL 1.0, so I'm
quite sure it's actually caused by the OpenSSL transition.)
So, in short, upgrading libcurl3 breaks existing binary packages.
According to our policy, that means a SONAME change would be necessary.
("Every time the shared library ABI changes in a way that may break
binaries linked against older versions of the shared library, the SONAME
of the library and the corresponding name for the binary package
containing the runtime shared library should change.")
But the way the OpenSSL transition was communicated, Alessando probably
didn't expect that the change would cause an ABI change.
How do we handle this?
For this single package, zurl, I could recompile with OpenSSL 1.1. This
seems to work, but I'm not sure if there are hidden issues, as zurl also
links to qt5, which is built against libssl1.0-dev.
But who knows which other packages are silently broken the same way?
Jan
Re: OpenSSL 1.1.0
On Fri, Nov 11, 2016 at 03:15:09PM +0100, Kurt Roeckx wrote: > At least something like that also came up with xmltooling. > It's probably caused by this: > curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, &sslCtxFunction_cb); > > You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0 > function with that handle. And libcurl really shouldn't have been > exposing such functions directly. If something like that is > really needed libcurl should have made a proper wrapper. Yes, I agree that libcurl shouldn't expose such functions. But it does, and it's to late to change that. By exposing that function, SSL_CTX became part of curl's ABI. So by linking to a different OpenSSL version with a different representation of SSL_CTX, curl indeed changed its ABI and must change SONAME, right? Jan
Re: OpenSSL 1.1.0
On Mon, Nov 14, 2016 at 10:45:50AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and > have libssl1.1-dev around for anyone who can really do the switch. That's the only viable alternative I see. It looks like an increasing number of packages, including apache2, openssh, qt4 and qt5, picked to build-depend on libssl1.0-dev. So OpenSSL 1.0 won't go away, and through packages indirectly depending on both versions, we'll get very difficult to solve conflicts. As removing all those packages clearly is not an option, the release will be significantly delayed if we don't revert the default to be OpenSSL 1.0. (It's fine if packages which depend on libssl-dev get an RC-bug if they can't be compiled with OpenSSL 1.1. Packages which can't be ported should explicitly depend on libssl1.0-dev. That way we'll make progress towards a point where we can start a smooth transition.) I'd be glad to have a quick transition to OpenSSL 1.1 now, but I honestly don't see a way how this may work. Please revert the default back to 1.0 for now. Jan
Re: OpenSSL 1.1.0
On Tue, Nov 15, 2016 at 10:43:07AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On lunes, 14 de noviembre de 2016 22:16:25 ART Jan Niehusmann wrote: > [snip] > > (It's fine if packages which depend on libssl-dev get an RC-bug if they > > can't be compiled with OpenSSL 1.1. Packages which can't be ported > > should explicitly depend on libssl1.0-dev. That way we'll make progress > > towards a point where we can start a smooth transition.) > > I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev > means that some apps/libs will get automatically recompiled and some of them > might even not FTBFS (because for example, they are ready to use 1.1). > > That means we left the door open to crashes due to mixed libssl versions. I probably didn't state that clear enough: I don't think libssl-dev should provide libssl1.1-dev. But building packages - purely for testing purposes - against libssl1.1-dev and reporting any issues is a good thing, and I even think such bugs could be marked RC, to make sure we make progress. At the same time, I don't want to remove packages which can't be ported quickly. Therefore, either these bugs can't be RC, or there must be an easy way for maintainers to opt out. One way of such an opt-out would be changing the dependency to libssl1.0-dev. However, the quoted paragraph was meant as a side-note only. It's not important, at the moment. The one thing we should decide *quickly* is if we want to revert libssl-dev back to 1.0, or if we want to delay the freeze by several months. > By letting libssl-dev provide libssl1.0 we do not open this door, and we let > maintainers decide on a per-basis case. Yes, and we avoid cases like with libcurl3, where the recompile to libssl1.1 broke ABI compatibility of libcurl3 without notice. Jan
Re: OpenSSL 1.1.0
Hi, On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote: > At the end I noticed that Qt will stay at 1.0 (by glancing into the > changelog of the relevant upload) which means that my package also has > to to stay at 1.0 and the whole excitement resulted in just a changed > build-dep. I'm not so sure about this any more: In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan Golosunov wrote that according to his understanding of dlsym(3), it should be fine to link a program with OpenSSL 1.1 and Qt at the same time, even though Qt links to OpenSSL 1.0. Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm that? If that's true, it would (IMHO) be a major step towards a timely release of stretch with OpenSSL 1.1 as the default version. Jan
Re: OpenSSL 1.1.0
On Thu, Nov 24, 2016 at 03:59:10PM +0200, Adrian Bunk wrote: > If inspection is not easily possible, then adding a dependency on > libssl1.0-dev to qtbase5-private-dev should be sufficient to > ensure that this is not leaked to a different OpenSSL version. I see two disadvantages: 1) doesn't catch cases where a package doesn't depend on libssl at all, but depends on two libraries which in turn use qt and libssl. 2) needlessly affects packages which use qt, but don't use QNetwork / QSsl. But I don't know a better alternative, either. Jan
Re: OpenSSL 1.1.0
On Thu, Nov 24, 2016 at 07:23:22PM +0200, Adrian Bunk wrote: > If both b-dev and c-dev would depend on the libssl*-dev they use, Which is not always the case, now. qtbase5-private-dev exposes lots of internal OpenSSL structures, but doesn't depend on any OpenSSL package. libcurl4-openssl-dev only suggests libssl-dev. And it provides access to an SSL_CTX via: typedef CURLcode (*curl_ssl_ctx_callback)(CURL *curl,/* easy handle */ void *ssl_ctx, /* actually an OpenSSL SSL_CTX */ void *userptr); It's working around a dependency by using a (void *) instead. So, at least in theory, a package using both qtbase5-private-dev and libcurl4-openssl-dev could relay an SSL_CTX between two different versions of OpenSSL. In practice, of course, its highly unlikely that a package links to two different libraries, accesses SSL-related functions in both of them, passes structures around, and does not depend on libssl-dev, itself. Therefore I think this is a red herring. The more important question is if there are any risks left if there are no structures exchanged between the two versions of OpenSSL. Which, in turn, boils down to the question of dlopen()/dlsym() do the right thing. If this usage is not OK, we need to make sure no package using Qt (and, in any of its use-cases triggering an SSL connection via Qt), links to OpenSSL 1.1, directly or indirectly. And indirect usage can't be prevented with the build-dependency Adrian suggests. If, instead, such usage is fine, only (dev-)packages exposing SSL structures need to be protected by a build-dependency on libssl-dev. That would be libcurl4-openssl-dev, qtbase5-private-dev and probably some others I don't know about. Jan
Re: OpenSSL 1.1.0
On Fri, Nov 25, 2016 at 01:56:19AM +0400, Stepan Golosunov wrote: > qsslsocket_openssl_symbols.cpp also tries to load any libssl.* it can > find (in directories gathered from dl_iterate_phdr) when it cannot > find libssl.so.. This asks for trouble when > libssl1.0.2 is not installed and probably needs to be patched out. This should be covered by qt 5.7.1~20161021+dfsg-6 (currently in sid). >From the changelog: "Make libqt5network5 depend on libssl1.0.2. It will crash when only newer libssl versions are installed." Jan
Bug#858345: ITP: tnetstring3 -- python3 library for data serialization using typed netstrings
Package: wnpp Severity: wishlist Owner: Jan Niehusmann * Package name: tnetstring3 Version : 0.3.1 Upstream Author : Carlo Pires * URL : https://pypi.python.org/pypi/tnetstring3 * License : MIT Programming Lang: Python / C Description : python3 library for data serialization using typed netstrings Tnetstring is a lot like JSON but it uses a new syntax called "typed netstrings" that was proposed for use in the Mongrel2 webserver. It's designed to be simpler and easier to implement than JSON, with a happy consequence of also being faster in many cases. This Python library provided functions to read and write tnetstrings. It's a port of the python2 tnetstring library. The python2 version is available in debian as package 'tnetstring'. I was asked by users of that package if I could package the python3 version, as well.
