Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Chris Wilson]

Hi Reinhard,

I don't blame you. I think that for Debian to upgrade a package, changing a
global setting, break some of its dependencies, and then kick out the
resulting broken packages a month later (nearly a year before the expected
release date) seems pretty harsh. In this case it took me 4.5 months to fix
the issue from when you reported it to me, so unless a package has at least
one full-time developer, a month simply isn't enough to fix this issue. Not
even close for a hobbyist like myself.

Thanks, Chris.

On Sun, 9 Jun 2019 at 23:26, Reinhard Tartler  wrote:

> Agreed!
>
> In this case, the bug was reported on Aug 24 2018 by Adrian Bunk. It was
> removed about a months later, namely on September 23, for failing to build
> from source. Four weeks is arguably quite fast. Or quite slow, depending on
> whom you talk to.
>
> I probably could have reacted by disabling the test suite. Or by prodding
> you in those four weeks harder. Or at last have the bug fixed by end of
> last year, which would have left enough time to re-migrate to testing. In
> the future, I'll know better.
>
> Again, sorry. I'm happy to help with getting the package to
> buster-backports once it opens.
>
> -rt
>
> On Sun, Jun 9, 2019 at 5:29 PM Chris Wilson 
> wrote:
>
>> Hi all,
>>
>> It seems a bit egregious to kick out packages that were broken by a minor
>> version upgrade in one of their dependencies (which after all is not
>> supposed to break anything), without any warning, let alone time to fix
>> such a complex issue properly.
>>
>> I hope that Debian will consider carefully whether this course of action
>> was really in the best interests of its users.
>>
>> Thanks, Chris.
>>
>
> --
> regards,
> Reinhard
>

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

Agreed!

In this case, the bug was reported on Aug 24 2018 by Adrian Bunk. It was
removed about a months later, namely on September 23, for failing to build
from source. Four weeks is arguably quite fast. Or quite slow, depending on
whom you talk to.

I probably could have reacted by disabling the test suite. Or by prodding
you in those four weeks harder. Or at last have the bug fixed by end of
last year, which would have left enough time to re-migrate to testing. In
the future, I'll know better.

Again, sorry. I'm happy to help with getting the package to
buster-backports once it opens.

-rt

On Sun, Jun 9, 2019 at 5:29 PM Chris Wilson 
wrote:

> Hi all,
>
> It seems a bit egregious to kick out packages that were broken by a minor
> version upgrade in one of their dependencies (which after all is not
> supposed to break anything), without any warning, let alone time to fix
> such a complex issue properly.
>
> I hope that Debian will consider carefully whether this course of action
> was really in the best interests of its users.
>
> Thanks, Chris.
>

-- 
regards,
Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Chris Wilson]

Hi all,

It seems a bit egregious to kick out packages that were broken by a minor 
version upgrade in one of their dependencies (which after all is not supposed 
to break anything), without any warning, let alone time to fix such a complex 
issue properly.

I hope that Debian will consider carefully whether this course of action was 
really in the best interests of its users. 

Thanks, Chris. 

Sent from my iPhone

> On 7 Jun 2019, at 22:26, Reinhard Tartler  wrote:
> 
> 
> 
>> On Wed, Jun 5, 2019 at 7:46 PM Chris Wilson  wrote:
>> Hi Reinhard,
>> 
>> Could you have a look at this patch (documented here) to see if it's 
>> something like what you were hoping for?
>> 
> 
> Hi Chris,
> 
> I've uploaded this patch now to unstable, looks good, thanks for the patch. 
> It is still about 80k big, thoguh :-( - quite a lot to review manually. Most 
> of it is actually test code though!
> 
> Unfortunately, I have bad news. I totally missed that boxbackup has already 
> been removed on 23 Sep 2018: 
> https://tracker.debian.org/news/989096/boxbackup-removed-from-testing/
> That's a bummer, because the freeze guidelines rule out migration of packages 
> that aren't part of testing since beginning of February (cf. 
> https://release.debian.org/buster/freeze_policy.html).
> 
> Sorry about that, that's totally on me, I should have been more vocal about 
> this end of last year and totally dropped the ball here.
> 
> I guess we'll have to go the backports route then.
> 
> Best,
> -rt
> -- 
> regards,
> Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

On Wed, Jun 5, 2019 at 7:46 PM Chris Wilson  wrote:

> Hi Reinhard,
>
> Could you have a look at this patch
>  (documented
> here
> )
> to see if it's something like what you were hoping for?
>
>
Hi Chris,

I've uploaded this patch now to unstable, looks good, thanks for the patch.
It is still about 80k big, thoguh :-( - quite a lot to review manually.
Most of it is actually test code though!

Unfortunately, I have bad news. I totally missed that boxbackup has already
been removed on 23 Sep 2018:
https://tracker.debian.org/news/989096/boxbackup-removed-from-testing/
That's a bummer, because the freeze guidelines rule out migration of
packages that aren't part of testing since beginning of February (cf.
https://release.debian.org/buster/freeze_policy.html).

Sorry about that, that's totally on me, I should have been more vocal about
this end of last year and totally dropped the ball here.

I guess we'll have to go the backports route then.

Best,
-rt
-- 
regards,
Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Chris Wilson]

Hi Reinhard,

Could you have a look at this patch
 (documented
here
)
to see if it's something like what you were hoping for?

Thanks, Chris.

On Fri, 31 May 2019 at 22:55, Reinhard Tartler  wrote:

>
>
> On Fri, May 31, 2019 at 5:03 PM Chris Wilson 
> wrote:
>
>> Hi Reinhard,
>>
>> Presumably the many other affected packages have had similar difficulty
>> in developing a comprehensive solution? I also wasn't aware of a time
>> constraint. Not that it would have helped me much, as I was moving house,
>> but it would have been good to know that there was a risk of not making
>> Debian 10.
>>
>
> I'm sorry, I should have communicated that point earlier. I've been bitten
> by this with other packages as well.
> The release schedule is documented here:
> https://wiki.debian.org/DebianBuster
> The most recent update from the release team is
> https://lists.debian.org/debian-devel-announce/2019/04/msg3.html -
> and newer updates will be linked from https://release.debian.org/.
>
> In short: The team is minimizing changes as much as possible, and getting
> updates in becomes more and more a similar big deal as updating something
> in stable.
>
> I could create a special branch with a cut-down version of the solution,
>> e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time
>> being, in order to get the fix out in time for Debian 10, and then put the
>> full version into backports?
>>
>
> That would be amazing, if the patch is easy to review, I'd be happy to
> upload it as a distro patch based on the current package and try to get
> this approved by the release team. It might even be accepted as a stable
> update, depending on how invasive it is.
>
>
> Thanks,
> -rt
>
>

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

On Fri, May 31, 2019 at 5:03 PM Chris Wilson  wrote:

> Hi Reinhard,
>
> Presumably the many other affected packages have had similar difficulty in
> developing a comprehensive solution? I also wasn't aware of a time
> constraint. Not that it would have helped me much, as I was moving house,
> but it would have been good to know that there was a risk of not making
> Debian 10.
>

I'm sorry, I should have communicated that point earlier. I've been bitten
by this with other packages as well.
The release schedule is documented here:
https://wiki.debian.org/DebianBuster
The most recent update from the release team is
https://lists.debian.org/debian-devel-announce/2019/04/msg3.html - and
newer updates will be linked from https://release.debian.org/.

In short: The team is minimizing changes as much as possible, and getting
updates in becomes more and more a similar big deal as updating something
in stable.

I could create a special branch with a cut-down version of the solution,
> e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time
> being, in order to get the fix out in time for Debian 10, and then put the
> full version into backports?
>

That would be amazing, if the patch is easy to review, I'd be happy to
upload it as a distro patch based on the current package and try to get
this approved by the release team. It might even be accepted as a stable
update, depending on how invasive it is.


Thanks,
-rt

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Chris Wilson]

Hi Reinhard,

Presumably the many other affected packages have had similar difficulty in
developing a comprehensive solution? I also wasn't aware of a time
constraint. Not that it would have helped me much, as I was moving house,
but it would have been good to know that there was a risk of not making
Debian 10.

I could create a special branch with a cut-down version of the solution,
e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time
being, in order to get the fix out in time for Debian 10, and then put the
full version into backports?

Thanks, Chris.

On Fri, 31 May 2019 at 12:16, Reinhard Tartler  wrote:

> Hi Chris,
>
> On Sun, May 19, 2019 at 12:21 PM Chris Wilson 
> wrote:
>
>> Hi Reinhard and all,
>>
>> Good news, I have just finished fixing this problem, and merged it into
>> master with https://github.com/boxbackup/boxbackup/pull/36. Please could
>> you cut a new Debian package release and see if the tests pass for you? Or
>> if not, point me to the failure logs?
>>
>> If anyone wants to know more, the issue is quite complex, and there are
>> no easy answers, which is why it took so long to fix. I've done my best to
>> describe it at
>> https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please
>> feel free to correct any mistakes that I've made.
>>
>
> Thanks a lot for your assistance!
>
> I've now (finally) uploaded the package to debian/experimental, the build
> logs will be available at
> https://buildd.debian.org/status/package.php?p=boxbackup=experimental
>  soon.
>
> Unfortunately, the changes are quite invasive and do not qualify for
> inclusion into "Debian testing" this late in the Debian release cycle (cf.
> https://salsa.debian.org/debian/boxbackup/commit/6017757bc079f4446aa77bc5c0855c52741280f4?w=1
> - all of which would need to be reviewed and approved by the Release Team).
> That's very unfortunate, because it very likely means that boxbackup will
> not be part of Debian 10 (buster).
>
> I am also sympathetic -- the nature of the issue seems to require such
> invasive changes and coming up with a simple, focused and reviewable fix is
> super hard.
>
> The best that we can do at this point is to get it included into
> "buster-backports" as soon as that suite opens, probably shortly after
> buster is released, which should be within (hopefully) a small number of
> weeks.
>
>
> Best,
> -rt
>
> --
> regards,
> Reinhard
>

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

Hi Chris,

On Sun, May 19, 2019 at 12:21 PM Chris Wilson 
wrote:

> Hi Reinhard and all,
>
> Good news, I have just finished fixing this problem, and merged it into
> master with https://github.com/boxbackup/boxbackup/pull/36. Please could
> you cut a new Debian package release and see if the tests pass for you? Or
> if not, point me to the failure logs?
>
> If anyone wants to know more, the issue is quite complex, and there are no
> easy answers, which is why it took so long to fix. I've done my best to
> describe it at
> https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please
> feel free to correct any mistakes that I've made.
>

Thanks a lot for your assistance!

I've now (finally) uploaded the package to debian/experimental, the build
logs will be available at
https://buildd.debian.org/status/package.php?p=boxbackup=experimental
 soon.

Unfortunately, the changes are quite invasive and do not qualify for
inclusion into "Debian testing" this late in the Debian release cycle (cf.
https://salsa.debian.org/debian/boxbackup/commit/6017757bc079f4446aa77bc5c0855c52741280f4?w=1
- all of which would need to be reviewed and approved by the Release Team).
That's very unfortunate, because it very likely means that boxbackup will
not be part of Debian 10 (buster).

I am also sympathetic -- the nature of the issue seems to require such
invasive changes and coming up with a simple, focused and reviewable fix is
super hard.

The best that we can do at this point is to get it included into
"buster-backports" as soon as that suite opens, probably shortly after
buster is released, which should be within (hopefully) a small number of
weeks.


Best,
-rt

-- 
regards,
Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Chris Wilson]

Hi Reinhard and all,

Good news, I have just finished fixing this problem, and merged it into
master with https://github.com/boxbackup/boxbackup/pull/36. Please could
you cut a new Debian package release and see if the tests pass for you? Or
if not, point me to the failure logs?

If anyone wants to know more, the issue is quite complex, and there are no
easy answers, which is why it took so long to fix. I've done my best to
describe it at
https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please
feel free to correct any mistakes that I've made.

Thanks, Chris.

On Sun, 10 Mar 2019 at 18:23, Reinhard Tartler  wrote:

> On Mon, Jan 7, 2019, 16:58 Chris Wilson >>
 Hi Reinhard,

 If I make the workaround suggested on this thread
  (change
 SECLEVEL to 1 in /etc/ssl/openssl.cnf) then test/basicserver passes again.
 This is at least a good start, so that users who don't want to replace
 their certificates have a workaround. I think I'll need to modify the CA
 scripts that generate certificates so that they produce 2048-bit keys that
 do not need this workaround, and document it or catch and improve the error
 message.


> Any progress on updating the CA scripts that generate certificates so that
> they produce 2048-bit keys?
>
> I've updated the package to git20180819.g2f5b556, but am still
> experiencing a test failure:
>
> make[1]: Leaving directory '/<>/test/basicserver'
> TEST: test/basicserver
> Killing any running daemons...
> Removing old test files...
> chmod: cannot access 'testfiles': No such file or directory
> Copying new test files...
> NOTICE:  Running test basicserver in debug mode...
> INFO:Starting server: ./_test --test-daemon-args= srv1
> testfiles/srv1.conf
> Waiting for server to die (pid 16575): . done.
> INFO:Starting server: ./_test --test-daemon-args= srv2
> testfiles/srv2.conf
> Waiting for server to die (pid 16579): . done.
> INFO:Starting server: ./_test --test-daemon-args= srv3
> testfiles/srv3.conf
> ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
> test/basicserver/testbasicserver.cpp:628
> ERROR:    TEST FAILURE: Condition [HUPServer(pid)] failed at
> test/basicserver/testbasicserver.cpp:631
> ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
> test/basicserver/testbasicserver.cpp:633
> ERROR:   SSL or crypto error: loading certificates from
> testfiles/clientCerts.pem: error:140AB18F:SSL
> routines:SSL_CTX_use_certificate:ee key too small
> WARNING: Exception thrown: ServerException(TLSLoadCertificatesFailed) at
> lib/server/TLSContext.cpp(93)
> FAILED: Exception caught: TLSLoadCertificatesFailed
>
>
>
> --
> regards,
> Reinhard
>

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

>
> On Mon, Jan 7, 2019, 16:58 Chris Wilson >
>>> Hi Reinhard,
>>>
>>> If I make the workaround suggested on this thread
>>>  (change
>>> SECLEVEL to 1 in /etc/ssl/openssl.cnf) then test/basicserver passes again.
>>> This is at least a good start, so that users who don't want to replace
>>> their certificates have a workaround. I think I'll need to modify the CA
>>> scripts that generate certificates so that they produce 2048-bit keys that
>>> do not need this workaround, and document it or catch and improve the error
>>> message.
>>>
>>>
Any progress on updating the CA scripts that generate certificates so that
they produce 2048-bit keys?

I've updated the package to git20180819.g2f5b556, but am still experiencing
a test failure:

make[1]: Leaving directory '/<>/test/basicserver'
TEST: test/basicserver
Killing any running daemons...
Removing old test files...
chmod: cannot access 'testfiles': No such file or directory
Copying new test files...
NOTICE:  Running test basicserver in debug mode...
INFO:Starting server: ./_test --test-daemon-args= srv1
testfiles/srv1.conf
Waiting for server to die (pid 16575): . done.
INFO:Starting server: ./_test --test-daemon-args= srv2
testfiles/srv2.conf
Waiting for server to die (pid 16579): . done.
INFO:Starting server: ./_test --test-daemon-args= srv3
testfiles/srv3.conf
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:628
ERROR:    TEST FAILURE: Condition [HUPServer(pid)] failed at
test/basicserver/testbasicserver.cpp:631
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:633
ERROR:   SSL or crypto error: loading certificates from
testfiles/clientCerts.pem: error:140AB18F:SSL
routines:SSL_CTX_use_certificate:ee key too small
WARNING: Exception thrown: ServerException(TLSLoadCertificatesFailed) at
lib/server/TLSContext.cpp(93)
FAILED: Exception caught: TLSLoadCertificatesFailed



-- 
regards,
Reinhard