| 2023-05-01 19:29:16 |
Harlan Lieberman-Berg |
bug |
|
|
added bug |
| 2023-05-01 19:59:43 |
Harlan Lieberman-Berg |
summary |
[SRU] Fix invalid CSR version in python-acme, kinetic |
[SRU] Fix invalid CSR version in python-acme, jammy |
|
| 2023-05-01 20:45:07 |
Harlan Lieberman-Berg |
attachment added |
|
debdiff from current jammy to fixed version https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/2018252/+attachment/5670139/+files/jammy.debdiff |
|
| 2023-05-01 20:45:49 |
Harlan Lieberman-Berg |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2023-05-01 20:47:11 |
Harlan Lieberman-Berg |
tags |
|
patch |
|
| 2023-05-01 21:45:39 |
Alex Gaynor |
bug |
|
|
added subscriber Alex Gaynor |
| 2023-05-02 01:18:45 |
Stefano Rivera |
attachment added |
|
focal.debdiff https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/2018252/+attachment/5670177/+files/focal.debdiff |
|
| 2023-05-02 01:18:53 |
Stefano Rivera |
summary |
[SRU] Fix invalid CSR version in python-acme, jammy |
[SRU] Fix invalid CSR version in python-acme |
|
| 2023-05-02 01:19:00 |
Stefano Rivera |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-05-02 01:19:00 |
Stefano Rivera |
bug task added |
|
python-acme (Ubuntu Jammy) |
|
| 2023-05-02 01:19:00 |
Stefano Rivera |
nominated for series |
|
Ubuntu Focal |
|
| 2023-05-02 01:19:00 |
Stefano Rivera |
bug task added |
|
python-acme (Ubuntu Focal) |
|
| 2023-05-02 01:19:13 |
Stefano Rivera |
python-acme (Ubuntu): status |
New |
Fix Released |
|
| 2023-05-02 01:19:37 |
Launchpad Janitor |
python-acme (Ubuntu Focal): status |
New |
Confirmed |
|
| 2023-05-02 01:19:37 |
Launchpad Janitor |
python-acme (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2023-05-02 01:31:10 |
Thomas Ward |
description |
[ Impact ]
This bug causes certbot to generate CSRs which are invalid. These CSRs are then sent to ACME servers or otherwise parsed. Some software validate CSR validity more aggressively, whichmeans it will reject these CSRs.
The principle motivation for backporting this fix is to stop certbot from generating CSRs. This will both alleviate bugs experienced by users, as well as reduce pressure on CSR parsers to accept _invalid_ CSRs.
[ Test plan ]
The patch contains a unit test that verifies the patch itself works correctly. It has been present in certbot upstream since the 1.29.0 release. Further, the fix was backported to both Debian and RHEL. Therefore, it has received substantial burn-in and is extremely unlikely to regress anything.
[ Where problems could occur ]
For a problem to occur, it would require software that not only accepted, but in fact _required_, an invalid CSR, and which also did not process CSRs from recent versions of certbot or versions from Debian or RHEL containing the backport.
The worst-case scenario for such software would be something that copied the version value from a CSR into a certificate it was issuing (CSRs have only a single valid version, v1. X.509 certificates can be either v1 or v3, however in practice v3 is the only version in use.). Such software would end up producing different (and less correct/compatible) certificates. I am not aware of any software with this behavior.
A more likely (though still improbable) bug would be software which merely asserts that the CSR's version is something incorrect.
This relates to LP#: 2004073. |
[ Impact ]
This bug causes certbot to generate CSRs which are invalid. These CSRs are then sent to ACME servers or otherwise parsed. Some software validate CSR validity more aggressively, whichmeans it will reject these CSRs.
The principle motivation for backporting this fix is to stop certbot from generating CSRs. This will both alleviate bugs experienced by users, as well as reduce pressure on CSR parsers to accept _invalid_ CSRs.
[ Test plan ]
The patch contains a unit test that verifies the patch itself works correctly. It has been present in certbot upstream since the 1.29.0 release. Further, the fix was backported to both Debian and RHEL. Therefore, it has received substantial burn-in and is extremely unlikely to regress anything.
[ Where problems could occur ]
For a problem to occur, it would require software that not only accepted, but in fact _required_, an invalid CSR, and which also did not process CSRs from recent versions of certbot or versions from Debian or RHEL containing the backport.
The worst-case scenario for such software would be something that copied the version value from a CSR into a certificate it was issuing (CSRs have only a single valid version, v1. X.509 certificates can be either v1 or v3, however in practice v3 is the only version in use.). Such software would end up producing different (and less correct/compatible) certificates. I am not aware of any software with this behavior.
A more likely (though still improbable) bug would be software which merely asserts that the CSR's version is something incorrect. |
|
| 2023-05-02 01:36:13 |
Stefano Rivera |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-05-12 18:24:23 |
Paul Tagliamonte |
bug |
|
|
added subscriber Paul Tagliamonte |
| 2023-05-13 00:29:59 |
Steve Langasek |
python-acme (Ubuntu Jammy): status |
Confirmed |
Incomplete |
|
| 2023-05-16 15:59:17 |
Benjamin Drung |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2023-05-24 20:15:19 |
Mathias Ertl |
attachment added |
|
ubuntu-2018252.tar.gz https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/2018252/+attachment/5675469/+files/ubuntu-2018252.tar.gz |
|
| 2023-05-26 23:28:24 |
Steve Langasek |
description |
[ Impact ]
This bug causes certbot to generate CSRs which are invalid. These CSRs are then sent to ACME servers or otherwise parsed. Some software validate CSR validity more aggressively, whichmeans it will reject these CSRs.
The principle motivation for backporting this fix is to stop certbot from generating CSRs. This will both alleviate bugs experienced by users, as well as reduce pressure on CSR parsers to accept _invalid_ CSRs.
[ Test plan ]
The patch contains a unit test that verifies the patch itself works correctly. It has been present in certbot upstream since the 1.29.0 release. Further, the fix was backported to both Debian and RHEL. Therefore, it has received substantial burn-in and is extremely unlikely to regress anything.
[ Where problems could occur ]
For a problem to occur, it would require software that not only accepted, but in fact _required_, an invalid CSR, and which also did not process CSRs from recent versions of certbot or versions from Debian or RHEL containing the backport.
The worst-case scenario for such software would be something that copied the version value from a CSR into a certificate it was issuing (CSRs have only a single valid version, v1. X.509 certificates can be either v1 or v3, however in practice v3 is the only version in use.). Such software would end up producing different (and less correct/compatible) certificates. I am not aware of any software with this behavior.
A more likely (though still improbable) bug would be software which merely asserts that the CSR's version is something incorrect. |
[ Impact ]
This bug causes certbot to generate CSRs which are invalid. These CSRs are then sent to ACME servers or otherwise parsed. Some software validate CSR validity more aggressively, whichmeans it will reject these CSRs.
The principle motivation for backporting this fix is to stop certbot from generating CSRs. This will both alleviate bugs experienced by users, as well as reduce pressure on CSR parsers to accept _invalid_ CSRs.
[ Test plan ]
See https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/2018252/comments/11 for complete test plan including links to assets.
[ Where problems could occur ]
For a problem to occur, it would require software that not only accepted, but in fact _required_, an invalid CSR, and which also did not process CSRs from recent versions of certbot or versions from Debian or RHEL containing the backport.
The worst-case scenario for such software would be something that copied the version value from a CSR into a certificate it was issuing (CSRs have only a single valid version, v1. X.509 certificates can be either v1 or v3, however in practice v3 is the only version in use.). Such software would end up producing different (and less correct/compatible) certificates. I am not aware of any software with this behavior.
A more likely (though still improbable) bug would be software which merely asserts that the CSR's version is something incorrect. |
|
| 2023-05-26 23:28:37 |
Steve Langasek |
python-acme (Ubuntu Jammy): status |
Incomplete |
Fix Committed |
|
| 2023-05-26 23:28:39 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2023-05-26 23:28:45 |
Steve Langasek |
tags |
patch |
patch verification-needed verification-needed-jammy |
|
| 2023-05-26 23:35:43 |
Steve Langasek |
python-acme (Ubuntu Focal): status |
Confirmed |
Fix Committed |
|
| 2023-05-26 23:35:48 |
Steve Langasek |
tags |
patch verification-needed verification-needed-jammy |
patch verification-needed verification-needed-focal verification-needed-jammy |
|
| 2023-05-27 14:09:22 |
Alex Gaynor |
tags |
patch verification-needed verification-needed-focal verification-needed-jammy |
patch verification-done-focal verification-done-jammy verification-needed |
|
| 2023-06-05 09:20:31 |
Launchpad Janitor |
python-acme (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-06-05 09:20:35 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-06-07 13:22:12 |
Launchpad Janitor |
python-acme (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
