[zypp-devel] "must see" advisories for security updates, distro upgrades, OBS
Hallo. I am thinking again about a correct way to notify users about "must see" advisory, which may appear for some security updates. It typically happens for opensc and I need to display: "Package update is not sufficient. Please follow following instructions to make your crypto tokens secure..." It should be displayed: - On security updated - In OBS repository while upgrading from unfixed to fixed version - During distro upgrade (customer upgrades from unpatched SLE10 SP1 to fixed SLE11 opensc => display the advisory) Ways used in past did not cover all cases. People complained, that the advisory pop-up blocks update. https://bugzilla.novell.com/show_bug.cgi?id=429786 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stanislav Brabec wrote:
Hallo.
I am thinking again about a correct way to notify users about "must see" advisory, which may appear for some security updates.
It typically happens for opensc and I need to display: "Package update is not sufficient. Please follow following instructions to make your crypto tokens secure..."
It should be displayed:
- On security updated
- In OBS repository while upgrading from unfixed to fixed version
- During distro upgrade (customer upgrades from unpatched SLE10 SP1 to fixed SLE11 opensc => display the advisory)
Ways used in past did not cover all cases. People complained, that the advisory pop-up blocks update.
Hi, just to summarize, we need notification mechanism for package updates. All we currently have is the output from rpm (which gets printed only in zypper, and can be easily overlooked). Does insnotify()/delnotify() work (where in the .spec file does one set it)? Can we use it? Bubli said it worked, but was too annoying and removed from UIs - maybe it wasn't used only for "must see" messages... we need to do it: - interactively - show message and wait until the user hits a key to continue - non-interactively, if non-interactive mode is requested - log somewhere and, at the end, tell the user where s/he will find additional info about pending actions. -- cheers, jano Ján Kupec YaST team ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz ---------------------------------------------------------(EOF)---
On Thursday 07 May 2009 19:06:56 Jano Kupec wrote:
Hi, just to summarize, we need notification mechanism for package updates. All we currently have is the output from rpm (which gets printed only in zypper, and can be easily overlooked).
Isn't this Bug 450093 - update-messages functionality not implemented Fate 301175 -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thursday 07 May 2009 20:00:47 Michael Andres wrote:
On Thursday 07 May 2009 19:06:56 Jano Kupec wrote:
Hi, just to summarize, we need notification mechanism for package updates. All we currently have is the output from rpm (which gets printed only in zypper, and can be easily overlooked).
Isn't this
Bug 450093 - update-messages functionality not implemented Fate 301175
A bit more verbose: We have - Messages associated with patches. Those messages are part of the patch metadata. Shown at the beginning of commit via a callback. The callback returning FALSE will abort commit. - Messages and Scripts which can be installed by any package. After commit all newly installed scripts are executed (available in code 11). All newly installed messages will be shown via a callback, similar to patch messages (to be implented). Depending on the mode (interactive/non-interactive) you can use different callback recipients, which either show and/or collect the messages. AFAIK not yet defined is the format of the packages message file. By now we'd assume it's plain (utf8)text. But we probably could define some magic, that allows to ship translated texts as well. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Does insnotify()/delnotify() work (where in the .spec file does one set it)? Can we use it? Bubli said it worked, but was too annoying and removed from UIs - maybe it wasn't used only for "must see" messages...
Oh, it wasn't exactly what I said and how it works in UIs now :) insnotify()/delnotify() messages are now displayed iff it is user himself who selects package for installation/deletion (i.e. it is not solver or something else). What was removed from UIs was displaying these messages on updating the package, the frequent argument against being that it slows down system update, and the user has to be there and click these messages away as they pop-up in the course of update. In addition to the bug mentioned above, here is another one: https://bugzilla.novell.com/show_bug.cgi?id=308410 B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Katarina Machalkova wrote:
Does insnotify()/delnotify() work (where in the .spec file does one set it)? Can we use it? Bubli said it worked, but was too annoying and removed from UIs - maybe it wasn't used only for "must see" messages...
Oh, it wasn't exactly what I said and how it works in UIs now :) insnotify()/delnotify() messages are now displayed iff it is user himself who selects package for installation/deletion (i.e. it is not solver or something else).
What was removed from UIs was displaying these messages on updating the package, the frequent argument against being that it slows down system update, and the user has to be there and click these messages away as they pop-up in the course of update. In addition to the bug mentioned above, here is another one: https://bugzilla.novell.com/show_bug.cgi?id=308410
Thanx for correcting me :O) This is something that we could solve by logging the messages somewhere and notifying the user at the end of installation iff there were some "must see" messages. This would be the non-interactive mode i mentioned earlier. The question is whether _all_ the insnotify()/delnotify() messages should be "must see" or we need a way to distinguish between "must see" and "nice to see, but not really required". -- cheers, jano Ján Kupec YaST team ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz ---------------------------------------------------------(EOF)---
On Thu, May 07, 2009 at 07:06:56PM +0200, Jano Kupec wrote:
- interactively - show message and wait until the user hits a key to continue
And don't do that in the transaction, show them either before or afterwards.
- non-interactively, if non-interactive mode is requested - log somewhere and, at the end, tell the user where s/he will find additional info about pending actions.
Weren't the Ubuntu folks working on some generic notification mechanism? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jano Kupec wrote:
Hi, just to summarize, we need notification mechanism for package updates. All we currently have is the output from rpm (which gets printed only in zypper, and can be easily overlooked).
Not only that.
Does insnotify()/delnotify() work (where in the .spec file does one set it)? Can we use it? Bubli said it worked, but was too annoying and removed from UIs - maybe it wasn't used only for "must see" messages...
It is not sufficient. You want to tell user this fact only once, only and only if the old version was vulnerable and the new is not. This is different from insnotify(), which is called every time package is updated. As nobody is forced to install each update (especially in OBS), you cannot do it just for a single versions. It can even happen that one is updating from vulnerable SLES10 to fixed SLES11. Even then displaying of "must see" advisory is important. In the best case user should be warned every time package management is started online (from command line or GUI) until user confirms that advisory was read and action was taken (or considered not being affected). Confirming this message should be even more privileged action than installing a security update itself - on a typical desktop it's OK to click OK for update by user, but it's not OK to click "I reformatted all smart cards" by user. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Monday 11 May 2009 18:26:10 Stanislav Brabec wrote:
It is not sufficient. You want to tell user this fact only once, only and only if the old version was vulnerable and the new is not.
This is different from insnotify(), which is called every time package is updated.
As nobody is forced to install each update (especially in OBS), you cannot do it just for a single versions.
It can even happen that one is updating from vulnerable SLES10 to fixed SLES11. Even then displaying of "must see" advisory is important.
So you want the advisory metadata to be a list of condition (translated?) text condition (translated?) text ... Where the conditions are evaluated based on the pre-commit state of the system. If the condition is met, the text snippet is included in the final advisory. Condition might be more than just a version or version range, e.g. if some vulnerability was fixed by replacing/renaming a package? Things may become tricky, if you update a package while a still unconfirmed advisory for the old version is present, esp. if the new version also ships an advisory. I guess deleting the package should delete the advisory. Advisory metadata should be available, even if the package was installed by non-SUSE tools?
In the best case user should be warned every time package management is started online (from command line or GUI) until user confirms that advisory was read and action was taken (or considered not being affected).
Confirming this message should be even more privileged action than installing a security update itself - on a typical desktop it's OK to click OK for update by user, but it's not OK to click "I reformatted all smart cards" by user.
The final advisory had to be placed somewhere in the filesystem, so you can nag the user until he confirmed. We could think about including advisory metadata in the rpm-package. E.g as file in /var/adm/update-advisories/<package>-<version>. Similar to ../update-messages. So they get installed and vanish together with the package. As a goody, zypp post commit could check for newly installed advisories, maybe beautify them, and maintain the 'nag'-status. As a consequence, the advisory metadata are not available until the package is actually installed. If we'd need to show this info in advance, we'd need to duplicate them into the repos package metadata. Maybe we can even unify update-advisories and update-messages. There's not much difference. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Tue, 2009-05-19 at 13:09 +0200, Michael Andres wrote:
It can even happen that one is updating from vulnerable SLES10 to fixed SLES11. Even then displaying of "must see" advisory is important.
So you want the advisory metadata to be a list of
condition (translated?) text condition (translated?) text ...
Where the conditions are evaluated based on the pre-commit state of the system. If the condition is met, the text snippet is included in the final advisory. Condition might be more than just a version or version range, e.g. if some vulnerability was fixed by replacing/renaming a package?
Yes. (Well, there is a technical problem - Pre-commit version cannot be easily detected inside rpm %post scriptlets.)
Things may become tricky, if you update a package while a still unconfirmed advisory for the old version is present, esp. if the new version also ships an advisory.
Advisories have to be kept for the whole upgrade protection period.
I guess deleting the package should delete the advisory.
Probably yes.
Advisory metadata should be available, even if the package was installed by non-SUSE tools?
Advisories are available on the web and in the text file in docdir.
We could think about including advisory metadata in the rpm-package. E.g as file in /var/adm/update-advisories/<package>-<version>. Similar to ../update-messages. So they get installed and vanish together with the package.
Yes, it may be possible.
Maybe we can even unify update-advisories and update-messages. There's not much difference.
Yes. Some of update-messages have a similar nature. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stanislav Brabec wrote:
On Tue, 2009-05-19 at 13:09 +0200, Michael Andres wrote:
It can even happen that one is updating from vulnerable SLES10 to fixed SLES11. Even then displaying of "must see" advisory is important.
So you want the advisory metadata to be a list of
condition (translated?) text condition (translated?) text ...
Where the conditions are evaluated based on the pre-commit state of the system. If the condition is met, the text snippet is included in the final advisory. Condition might be more than just a version or version range, e.g. if some vulnerability was fixed by replacing/renaming a package?
Yes. (Well, there is a technical problem - Pre-commit version cannot be easily detected inside rpm %post scriptlets.)
Things may become tricky, if you update a package while a still unconfirmed advisory for the old version is present, esp. if the new version also ships an advisory.
Advisories have to be kept for the whole upgrade protection period.
I guess deleting the package should delete the advisory.
Probably yes.
Advisory metadata should be available, even if the package was installed by non-SUSE tools?
Advisories are available on the web and in the text file in docdir.
We could think about including advisory metadata in the rpm-package. E.g as file in /var/adm/update-advisories/<package>-<version>. Similar to ../update-messages. So they get installed and vanish together with the package.
Yes, it may be possible.
Maybe we can even unify update-advisories and update-messages. There's not much difference.
Yes. Some of update-messages have a similar nature.
Hi guys, what about creating a feature request for this? It looks like pretting good thing to me. Another use-case would be notification about conflicting configuration files during an upgrade (packager's version vs. user's version) (see https://features.opensuse.org/306411). -- cheers, jano Ján Kupec YaST team ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz ---------------------------------------------------------(EOF)---
Michael Schroeder wrote:
On Thu, May 07, 2009 at 07:06:56PM +0200, Jano Kupec wrote:
- interactively - show message and wait until the user hits a key to continue
And don't do that in the transaction, show them either before or afterwards.
- non-interactively, if non-interactive mode is requested - log somewhere and, at the end, tell the user where s/he will find additional info about pending actions.
Weren't the Ubuntu folks working on some generic notification mechanism?
Haven't heard about it. Got some pointers? -- cheers, jano Ján Kupec YaST team ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz ---------------------------------------------------------(EOF)---
On Fri, Jun 12, 2009 at 03:34:32PM +0200, Jano Kupec wrote:
Michael Schroeder wrote:
On Thu, May 07, 2009 at 07:06:56PM +0200, Jano Kupec wrote:
- interactively - show message and wait until the user hits a key to continue
And don't do that in the transaction, show them either before or afterwards.
- non-interactively, if non-interactive mode is requested - log somewhere and, at the end, tell the user where s/he will find additional info about pending actions.
Weren't the Ubuntu folks working on some generic notification mechanism?
Haven't heard about it. Got some pointers?
http://tech.slashdot.org/article.pl?sid=08/12/23/166245 http://www.markshuttleworth.com/archives/253 Micha. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (5)
-
Jano Kupec -
Katarina Machalkova -
Michael Andres -
Michael Schroeder -
Stanislav Brabec