** Description changed: [ Impact ] - * An explanation of the effects of the bug on users and justification - for backporting the fix to the stable release. + The OpenSSH package was split into GSSAPI/Kerberos and non- + GSSAPI/Kerberos variants, and they conflict with each other: - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + * openssh-server conflicts with openssh-server-gssapi (and vice-versa) + * openssh-client conflicts with openssh-client-gssapi (and vice-versa) + + When switching from one package to its counterpart, the conflicted + package will be removed (not purged), and stay in the “rc” state. This + is correct and expected. + + For example, if you had openssh-server installed, and switched to + openssh-server-gssapi, this is how both packages would be listed: + + rc openssh-server ... + ii openssh-server-gssapi ... + + If, however, while in this state, the removed package is purged, that + will break the openssh configuration due to the removal of essential + files still needed by the counterpart package, and remote access may be + lost. This is the case for both server and client openssh packages. + + This is documented in the Stonking release notes[1] as a known issue. + + The src:openssh-gssapi package made it to the stonking release (because + it's not seeded), but src:openssh still needs to be fixed. + + + 1. https://documentation.ubuntu.com/release-notes/26.10/#openssh-package-purge-can-break-openssh + [ Test Plan ] - * detailed instructions how to reproduce the bug + An autopkgtest was added to both src:openssh[2] and src:openssh- + gssapi[3] to test the fix for this bug. - * Ideally this is a well written and commented autopkgtest added as part - of the upload that way it is verified mostly by automation and will - ensure it is not breaking later + The test plan is therefore to have successful autopkgtest results, and + that this new test specifically was run and passed. - * When an autopkgtest isn't feasible the next best option is to - attach a script to the SRU bug that can be used in certain special - conditions/environments to recreate the issue - * When neither autopkgtest nor a test script is applicable please - outline the steps needed. These should allow someone who is not - familiar with the affected package to reproduce the bug and verify - that the updated package fixes the problem. - - * if other testing is appropriate to perform before landing this - update, this should also be described here. + 2. https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel + 3. https://git.launchpad.net/ubuntu/+source/openssh-gssapi/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + * Think about what the upload changes in the software. Imagine the + change is wrong or breaks something else: how would this show up? - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the event + of a regression. - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. + * This must never be "None" or "Low", or entirely an argument as to why + your upload is low risk. - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. [ Other Info ] - * Anything else you think is useful to include - - * Make sure to explain any deviation from the norm, to save the SRU - reviewer from having to infer your reasoning, possibly incorrectly. - This should also help reduce review iterations, particularly when the - reason for the deviation is not obvious. - - * Anticipate questions from users, SRU, +1 maintenance, security teams - and the Technical Board and address these questions in advance + Note that src:openssh-gssapi is in stonking release already, and + src:openssh was accepted into stonking-proposed prior to the stonking + release. [ Original Description ] From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1148080: If openssh-server is purged after openssh-server-gssapi is installed, the postrm script unconditionally removes configuration which it thinks still belongs to openssh-server, while in fact, openssh-server-gssapi has become the owner of that configuration. The deleted files involve the host keys, sshd_config, and systemd unit activation, rendering the SSH service unusable. openssh-client/openssh-client-gssapi has a similar problem, although it is less severe.
** Description changed: [ Impact ] The OpenSSH package was split into GSSAPI/Kerberos and non- GSSAPI/Kerberos variants, and they conflict with each other: * openssh-server conflicts with openssh-server-gssapi (and vice-versa) * openssh-client conflicts with openssh-client-gssapi (and vice-versa) When switching from one package to its counterpart, the conflicted package will be removed (not purged), and stay in the “rc” state. This is correct and expected. For example, if you had openssh-server installed, and switched to openssh-server-gssapi, this is how both packages would be listed: rc openssh-server ... ii openssh-server-gssapi ... If, however, while in this state, the removed package is purged, that will break the openssh configuration due to the removal of essential files still needed by the counterpart package, and remote access may be lost. This is the case for both server and client openssh packages. This is documented in the Stonking release notes[1] as a known issue. The src:openssh-gssapi package made it to the stonking release (because it's not seeded), but src:openssh still needs to be fixed. - - 1. https://documentation.ubuntu.com/release-notes/26.10/#openssh-package-purge-can-break-openssh - + 1. https://documentation.ubuntu.com/release-notes/26.10/#openssh- + package-purge-can-break-openssh [ Test Plan ] An autopkgtest was added to both src:openssh[2] and src:openssh- gssapi[3] to test the fix for this bug. The test plan is therefore to have successful autopkgtest results, and that this new test specifically was run and passed. - 2. https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel 3. https://git.launchpad.net/ubuntu/+source/openssh-gssapi/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + The fix is injecting an early exit on postrm of package A if it detects + that package B is installed. Likewise for package B if A is installed. + The risk here is making an incorrect decision, and preventing the postrm + hook from running when in fact it should. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. - - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. [ Other Info ] Note that src:openssh-gssapi is in stonking release already, and src:openssh was accepted into stonking-proposed prior to the stonking release. [ Original Description ] From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1148080: If openssh-server is purged after openssh-server-gssapi is installed, the postrm script unconditionally removes configuration which it thinks still belongs to openssh-server, while in fact, openssh-server-gssapi has become the owner of that configuration. The deleted files involve the host keys, sshd_config, and systemd unit activation, rendering the SSH service unusable. openssh-client/openssh-client-gssapi has a similar problem, although it is less severe. ** Description changed: [ Impact ] The OpenSSH package was split into GSSAPI/Kerberos and non- GSSAPI/Kerberos variants, and they conflict with each other: * openssh-server conflicts with openssh-server-gssapi (and vice-versa) * openssh-client conflicts with openssh-client-gssapi (and vice-versa) When switching from one package to its counterpart, the conflicted package will be removed (not purged), and stay in the “rc” state. This is correct and expected. For example, if you had openssh-server installed, and switched to openssh-server-gssapi, this is how both packages would be listed: rc openssh-server ... ii openssh-server-gssapi ... If, however, while in this state, the removed package is purged, that will break the openssh configuration due to the removal of essential files still needed by the counterpart package, and remote access may be lost. This is the case for both server and client openssh packages. This is documented in the Stonking release notes[1] as a known issue. The src:openssh-gssapi package made it to the stonking release (because it's not seeded), but src:openssh still needs to be fixed. 1. https://documentation.ubuntu.com/release-notes/26.10/#openssh- package-purge-can-break-openssh [ Test Plan ] An autopkgtest was added to both src:openssh[2] and src:openssh- gssapi[3] to test the fix for this bug. The test plan is therefore to have successful autopkgtest results, and that this new test specifically was run and passed. 2. https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel 3. https://git.launchpad.net/ubuntu/+source/openssh-gssapi/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel [ Where problems could occur ] The fix is injecting an early exit on postrm of package A if it detects that package B is installed. Likewise for package B if A is installed. The risk here is making an incorrect decision, and preventing the postrm hook from running when in fact it should. - [ Other Info ] Note that src:openssh-gssapi is in stonking release already, and src:openssh was accepted into stonking-proposed prior to the stonking release. + + The excuses[4] entry for openssh is clear. + + Specifically, the new test ran and passed[5]. + + + 4. https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#openssh + 5. https://autopkgtest.ubuntu.com/results/autopkgtest-stonking/stonking/amd64/o/openssh/20261011_190427_73a09@/log.gz#:~:text=ssh_known_hosts%0A1524s%20%0A1524s%20%23%23-,Test%20passed,-1524s%20autopkgtest%20%5B19 + [ Original Description ] From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1148080: If openssh-server is purged after openssh-server-gssapi is installed, the postrm script unconditionally removes configuration which it thinks still belongs to openssh-server, while in fact, openssh-server-gssapi has become the owner of that configuration. The deleted files involve the host keys, sshd_config, and systemd unit activation, rendering the SSH service unusable. openssh-client/openssh-client-gssapi has a similar problem, although it is less severe. ** Description changed: [ Impact ] The OpenSSH package was split into GSSAPI/Kerberos and non- GSSAPI/Kerberos variants, and they conflict with each other: * openssh-server conflicts with openssh-server-gssapi (and vice-versa) * openssh-client conflicts with openssh-client-gssapi (and vice-versa) When switching from one package to its counterpart, the conflicted package will be removed (not purged), and stay in the “rc” state. This is correct and expected. For example, if you had openssh-server installed, and switched to openssh-server-gssapi, this is how both packages would be listed: rc openssh-server ... ii openssh-server-gssapi ... If, however, while in this state, the removed package is purged, that will break the openssh configuration due to the removal of essential files still needed by the counterpart package, and remote access may be lost. This is the case for both server and client openssh packages. This is documented in the Stonking release notes[1] as a known issue. The src:openssh-gssapi package made it to the stonking release (because it's not seeded), but src:openssh still needs to be fixed. 1. https://documentation.ubuntu.com/release-notes/26.10/#openssh- package-purge-can-break-openssh [ Test Plan ] An autopkgtest was added to both src:openssh[2] and src:openssh- gssapi[3] to test the fix for this bug. The test plan is therefore to have successful autopkgtest results, and that this new test specifically was run and passed. 2. https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel 3. https://git.launchpad.net/ubuntu/+source/openssh-gssapi/tree/debian/tests/purge-keeps-config-with-counterpart?h=ubuntu/stonking-devel [ Where problems could occur ] The fix is injecting an early exit on postrm of package A if it detects that package B is installed. Likewise for package B if A is installed. The risk here is making an incorrect decision, and preventing the postrm hook from running when in fact it should. [ Other Info ] Note that src:openssh-gssapi is in stonking release already, and src:openssh was accepted into stonking-proposed prior to the stonking release. The excuses[4] entry for openssh is clear. Specifically, the new test ran and passed[5]. + A hint[6] had to be added for the openssh/i386 autopkgtest run, because + src:openssh-gssapi (the counterpart in this scenario) is not built for + i386, and the test would fail. The proper fix will be to skip the test + on i386 architecture, to be proposed for a future SRU. 4. https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#openssh 5. https://autopkgtest.ubuntu.com/results/autopkgtest-stonking/stonking/amd64/o/openssh/20261011_190427_73a09@/log.gz#:~:text=ssh_known_hosts%0A1524s%20%0A1524s%20%23%23-,Test%20passed,-1524s%20autopkgtest%20%5B19 - [ Original Description ] From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1148080: If openssh-server is purged after openssh-server-gssapi is installed, the postrm script unconditionally removes configuration which it thinks still belongs to openssh-server, while in fact, openssh-server-gssapi has become the owner of that configuration. The deleted files involve the host keys, sshd_config, and systemd unit activation, rendering the SSH service unusable. openssh-client/openssh-client-gssapi has a similar problem, although it is less severe. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2169738 Title: Purging openssh-server after installing openssh-server-gssapi deletes data and renders SSH unusable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2169738/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
