Re: OpenSSL 1.1.0

[Russ Allbery]

Pau Garcia i Quiles  writes:

> Most upstreams have do not support 1.1.0 yet, and have no plans to
> support it in months. This will force Debian maintaners to rewrite
> OpenSSL code, which is a very sensitive part and may turn an (upstream)
> secure application into an insecure application due to incorrect
> patches.

Yeah, Shibboleth upstream had a similar reaction to the ones reported
here: they want to work on it, someone has started looking at it, but
since 1.0 is supported for several more years, they weren't expecting it
to be an immediate issue and weren't planning on pushing to finish the
support until late 2017.

My guess from seeing the changes for INN is that the vast majority of
packages, which use OpenSSL in a glancing or fairly straightforward way,
won't be difficult to convert.  But security and cryptographic software
that uses OpenSSL heavily and makes extensive use of its less common
corners may require quite a bit of work.  (I think most of it is
mechanical, but lots of mechanical changes are also high-risk because
they're mind-numbing and it's easy to make a small mistake that slips
through unnoticed.)

-- 
Russ Allbery (r...@debian.org)   

Re: OpenSSL 1.1.0

[Gert Wollny]

Am Mittwoch, den 29.06.2016, 22:38 +0200 schrieb Pau Garcia i Quiles:
> If possible, I would rather have both 1.0.2 and 1.1.0 in the archive,
> and move to 1.1.0 as upstream moves. I do not feel comfortable at all
> touching security-related stuff, it's not my specialty. Even less if
> we are talking about OpenSSL, known not to be the most friendly and
> intuitive APIs.

I'd like to second this. Working on a patch for qt4 taught me that this
transition is not going to be easy, and in this very case especially so
since during the qt4 package build no test suite is run to verify that
the changes don't break anything. 

I can understand that supporting two version of the library would be a
quite a burden, this is quite clear from just looking a the large
number of patches both packages carry, but considering that the Stretch
freeze is supposed to happen in less than six month, forcing a
transition now doesn't seem to be such a good idea to me.

best, 
Gert 

Bug#829039: ITP: lua-luv -- libuv bindings for lua

[Jason Pleau]

Package: wnpp
Severity: wishlist
Owner: Jason Pleau 

* Package name: lua-luv
  Version : 1.9.0-3
  Upstream Author : The Luvit Authors
* URL : https://github.com/luvit/luv
* License : Apache
  Programming Lang: C, Lua
  Description : libuv bindings for lua

libuv is a multi-platform support library with a focus on asynchronous I/O.

This package provides libuv bindings for the Lua programming language.


lua-luv is a dependency for lua-nvim (not yet packaged nor ITP'd), which in
turn is a dependency to run the tests for neovim, and in the future will likely
provide Lua bindings for neovim plugins.

I will maintain lua-luv in the pkg-lua team.

Re: insurace_notice_for_ed_CVge

[ed nelson]

Would  like to here more
On Jun 29, 2016 4:08 PM, "Tollef Fog Heen"  wrote:

> fgh Never Pay for Covered Auto Repairs Again
>
> 9$/month
>
> Check now for Confirmation
>
>
>
>
>
> unSubHere
>
> 0Pt0utHere  
> 
> !@#$%^&@#$%*&
>
>

Re: OpenSSL 1.1.0

[Pau Garcia i Quiles]

On Wed, Jun 29, 2016 at 9:49 PM, Moritz Mühlenhoff  wrote:

> Jérémy Lal  wrote
> > The openssl release strategy page [1] states:
> > Version 1.1.0 will be supported until 2018-04-30.
> > Version 1.0.2 will be supported until 2019-12-31 (LTS).
> >
> > Considering the dates, upstream authors using openssl 1.0.2 might not
> > migrate to the new api until 1.0.2 end of life.
> > Is it reasonnable, for security and human resources sake, to carry
> hundreds
> > of patches for a transition that will happen much more safely and
> naturally
> > later ?
>
> Certainly. 1.1 brings a lot of internal changes which will be beneficial in
> the long run. And of course's there a wide range of 1.1 features which
> will b
> e important during the lifetime of stretch (e.g. chacha20/poly1305
> support).
>
>
I beg to disagree.

IMHO the mandatory migration to OpenSSL 1.1.0 is happening too soon.

Most upstreams have do not support 1.1.0 yet, and have no plans to support
it in months. This will force Debian maintaners to rewrite OpenSSL code,
which is a very sensitive part and may turn an (upstream) secure
application into an insecure application due to incorrect patches.

If possible, I would rather have both 1.0.2 and 1.1.0 in the archive, and
move to 1.1.0 as upstream moves. I do not feel comfortable at all touching
security-related stuff, it's not my specialty. Even less if we are talking
about OpenSSL, known not to be the most friendly and intuitive APIs.

-- 
Pau Garcia i Quiles
http://www.elpauer.org

Re: OpenSSL 1.1.0

[Moritz Mühlenhoff]

Jérémy Lal  wrote
> The openssl release strategy page [1] states:
> Version 1.1.0 will be supported until 2018-04-30.
> Version 1.0.2 will be supported until 2019-12-31 (LTS).
>
> Considering the dates, upstream authors using openssl 1.0.2 might not
> migrate to the new api until 1.0.2 end of life.
> Is it reasonnable, for security and human resources sake, to carry hundreds
> of patches for a transition that will happen much more safely and naturally
> later ?

Certainly. 1.1 brings a lot of internal changes which will be beneficial in
the long run. And of course's there a wide range of 1.1 features which will b
e important during the lifetime of stretch (e.g. chacha20/poly1305 support).

Cheers,
Moritz

ITP: gnome-shell-extension-move-clock -- move clock extension for GNOME shell

[Jonathan Carter (highvoltage)]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-move-clock
  Version : 1.0.0
  Upstream Author : 2011-2013 Ron Yorston 
2016 Jonathan Carter 
* URL :
https://git.bluemosh.com/highvoltage/gnome-shell-extension-move-clock
* License : GPL-2+
  Programming Lang: JavaScript
  Description : move clock extension for GNOME shell

This extension will, when enabled, move the clock on your GNOME shell panel
from the middel to the right.
.
GNOME is an intuitive and attractive desktop. This is an add-on to
GNOME, and will likely not be useful on its own.

Bug#828997: ITP: libclass-ehierarchy-perl -- module that provides a base class for hierarchally ordered objects

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro 

* Package name: libclass-ehierarchy-perl
  Version : 0.93
  Upstream Author : Arthur Corliss 
* URL : https://metacpan.org/release/Class-EHierarchy
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module that provides a base class for hierarchally ordered 
objects

Class::EHierarchy is intended for use as a base class for custom objects, but  
objects that need one or more of the following features: orderly bottom-up 
destruction of objects, opaque objects, class-based access restrictions for
properties and methods, primitive strict property type awareness, alias-based  
object retrieval.

This package will be maintained under umbrella of Debian Perl team.

Bug#828962: ITP: r-cran-adephylo -- GNU R exploratory analyses for the phylogenetic comparative method

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-adephylo
  Version : 1.1-6
  Upstream Author : Thibaut Jombart 
* URL : https://cran.r-project.org/web/packages/adegenet/
* License : GPL
  Programming Lang: GNU R
  Description : GNU R exploratory analyses for the phylogenetic comparative 
method
 This GNU R package provides multivariate tools to analyze comparative
 data, i.e. a phylogeny and some traits measured for each taxa.


Remark: This package belongs to a pyramid of dependencies for the package
r-cran-treescape and will be maintained by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-adephylo/trunk/

Re: EVP_dss1 replacement?

[Christian Seiler]

On 06/29/2016 10:29 AM, Kurt Roeckx wrote:
> On Wed, Jun 29, 2016 at 04:15:39AM +0200, Christian Seiler wrote:
>> So is it correct to simply replace EVP_dss1() with EVP_sha1() in the
>> above code and it will still produce DSA signatures? Or do I have to do
>> something else to achieve the same results?
> 
> I'm not sure why they were removed at this time and not just
> replaced by a #define.
> 
> Using EVP_sha1() is the correct replacement for EVP_dss1(),
> as the manpage says.

Great, many thanks!

Regards,
Christian

Re: EVP_dss1 replacement? (was: OpenSSL 1.1.0)

[Kurt Roeckx]

On Wed, Jun 29, 2016 at 04:15:39AM +0200, Christian Seiler wrote:
> On 06/11/2016 02:30 PM, Kurt Roeckx wrote:
> > There is an upstream wiki page for this at:
> > https://wiki.openssl.org/index.php/1.1_API_Changes
> > 
> > If things aren't clear, you have questions, are there are missing
> > access functions please contact us.
> 
> I'm currently packaging a piece of software (open-isns, [1]) that uses
> libcrypto functions internally. While trying to make sure that it will
> compile against OpenSSL 1.1 (and hence be binNMU-able), most of the
> things were straight-forward (opaque structures now requiring getters),
> but I have encountered the following issue that doesn't appear to be
> completely trivial to me: the software uses DSA+SHA1 as its signature
> algoritm [2], and effectively boils down to the following code to
> generate signatures:
> 
> md_ctx = EVP_MD_CTX_new();
> EVP_SignInit(md_ctx, EVP_dss1());
> EVP_DigestUpdate(md_ctx, /* stuff */);
> EVP_SignFinal(md_ctx, signature, &sig_len, pkey);
> EVP_MD_CTX_free(md_ctx);
> 
> (Verification is analogous with VerifyInit/VerifyFinal.)
> 
> The problem is that EVP_dss1() doesn't exist anymore in OpenSSL 1.1. If
> I understand the man page correctly, EVP_dss1 is a hack in really old
> OpenSSL versions (how old btw.?) to support SHA1 signatures with DSA,
> because back then the hash algorithms were tied to the public key
> algorithms.
> 
> So is it correct to simply replace EVP_dss1() with EVP_sha1() in the
> above code and it will still produce DSA signatures? Or do I have to do
> something else to achieve the same results?

I'm not sure why they were removed at this time and not just
replaced by a #define.

Using EVP_sha1() is the correct replacement for EVP_dss1(),
as the manpage says.


Kurt

Bug#828940: ITP: python-dropbox -- Official Dropbox API Client

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-dropbox
  Version : 6.5.0
  Upstream Author : Dropbox Inc. 
* URL : https://github.com/dropbox/dropbox-sdk-python
* License : Expat
  Programming Lang: Python
  Description : Official Dropbox API Client


 A Python SDK for integrating with the Dropbox API v2. It offers a comprehensive
 set of features to interact with the Dropbox cloud service:
 .
  * OAuth2 authentication
  * File and folder manipulation
  * Managing shared links and folders

I will maintain this package as part of the DPMT and it is a dependency for the
dropbox backend in django-storages which I also plan to package.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXc3QfAAoJEGlMre9Rx7W25SEQAKze5trg3WFdOPeLnq93rq7e
vKMntVzlx+TfhlBW1N0ygthEMNscoJ7Pxwqa1z3pVqDgFSOOEi1ERLjZvUUO5ih1
la9Fp343cafcw3OzTKdsFkRawVwsph/Nl9VH+sfjjfJmbH4xusLflbKfBKqYMLsS
vstboaM4WzE5uvo8c8AaiLj1Y9HZp/riiE99hhIGD82v+y4J/M7i5sf0rX61lquP
A2og0zKmA18BlLkOvy1cmqbhGEXNoKuBnxN/0P3BPHcB75d6OTbDmRZvlPovMRRC
bDzVjkCFb6zO3r+6wteRFjQ3g+m6nFqqGAyH/bsEUz4lZApBz62zY76cmdF5Kdu9
YfIT/+JiZVIaludTVJNxCKum6nNtvrvj96hQRDcV6MhIAcqEO5JDJZ7/FfFuzNkb
imBHalGmVzHkQWSPi29iJWtS6xmNZFhnsixS2OXLhj0l1FYAy+ag1oJcWeA+koaX
7a21QNAtJZ7YSgX0XTThpxSZEKO1ZEqRWWsx6Es3998nyCTf61cFQnhfbjU8tvcj
fGwnIAKlJEw14vjg3VDGWbHs5uRV2U2ykgiQolHbEhxRiiS1m8jhMj7xqfrv6l+T
EQ2aTXcMyEhlfcJE/JpnRQBf35MKXu3n4jXGPJESrRAOmFDKrzlGVmZp2XYos1xo
L2QA99UwY512jVRgJKUp
=knTh
-END PGP SIGNATURE-