** Description changed: + [ Impact ] + + * An explanation of the effects of the bug on users and justification + for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. + + [ Test Plan ] + + * detailed instructions how to reproduce the 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 + + * 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. + + [ 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? + + * 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 ] + + * 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 + + [ 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
