The goal of this page is to identify current issues in the process of package updates and to confront currently proposed solutions to each of these issues, in order to determine how well they are addressed.

The issues currently identified, by the Ayatana Discussion members, are listed in the first part of this page. They will then be separately described in the second part. The third part lists the proposed solutions and their influence on each of the issues.

We need to voluntarily adopt a paranoid point of view regarding security updates. For every flaw is considered serious enough by the security expert people to be granted a SRU, we need to deploy a fix as fast as possible. History has shown that a (critical) security flaw could be exploited 6 days after it was unveiled. If we count a good 2/3 days in order to make the update available at download, it means the time left to fix it is short, and thus we need to make sure users will update within a few days in order to be totally safe.

Currently identified issues

Please add the issues you identify below, try to avoid duplicates. Don't modify or remove someone else's issue without discussion on the ML.

1. Some updates take effect only after a reboot
2. Some updates require an application to be restarted, otherwise this application doesn't work as expected
3. The update notification mechanisms should never be rude / intrusive towards the user, at the risk of the user trying to neutralize it
4. A fair proportion of users doesn't perform security updates fast enough

Issues in details

Why are they issues ? What are the negative consequences they have ?

1. Some updates take effect only after a reboot

Some updates, typically kernel and modules updates, take effect only after a reboot. Those updates, in the current Ubuntu stable releases, are allowed only if they are important security updates that need to be performed for the safety of the users. If the users don't reboot after performing the updates with the current implementation, they put themselves at risk till they reboot.

Even among users who do perform their security updates quickly, some may forget to shut their computer down and thus stay at risk.

2. Some updates require an application to be restarted, otherwise this application doesn't work as expected

Some applications, when updated, require an immediate restart in order to keep working. This is the case of at least one default application : Firefox. As the applications need to be restarted in order to keep working, this actually breaks the user's workflow.

3. The update notification mechanisms should never be rude / intrusive towards the user, at the risk of the user trying to neutralize it

Even if security issues are important and even if they may require some additional mechanisms than the normal updates, the goal of changes in the update-manager's policy is to increase the amount of people performing security updates.

If a majority of users (I consider this due to a very low level of expectation from users towards their OS) will accept intrusive or coercive methods for making them perform the updates, another part of the users may refuse anything they consider intrusive, and try to disable methods used to notify them of security updates. We should thus be looking for ways that will have a similar rate of fast updates with a consequently lesser rate of unhappy (end/average) users.

4. A fair proportion of users doesn't perform security updates fast enough

GNU/Linux is safer than other OSes because security breaches are unveiled, fixed and deployed faster than any OSes using a proprietary development model. If unveiling and fixing are usually performed extremely fast, deploying is often too slow - sometimes slow enough for a flaw to be exploited.

Some people will argue that they will be exploited on a little scale, but there are people who would benefit from an issue on a large number of machines (opponents, malicious hackers, commercial security products editors, etc.). The way we can avoid this is by making the deployment part as fast as possible, and hit the most important amount of machines possible. This is why security updates must be performed within days, and once the fix is patched and available in the repositories, we should have a 80% adoption rate in 3 days and a 90% adoption rate in a month.

Template For Ideas

Rationale

This is primarily designed to solve issue #X and #Y.

Description

Describe the idea in a few short paragraphs, almost exhaustively , ie. I should make sure that what I propose can be interpreted only one way, so that if people like my idea but think it is perfectible, they can edit it and make it better, without leaving too much room for differences of interpretation that would provoke the need for a rewrite and reevaluation during the implementation if my idea.

Consequences for issue #X

Describing the expected result for the issue you are trying to address. It should be done for all the aimed issues, and also the issues for which you suspect there will be negative consequences. I shall not do it at all for issues which are not concerned and upon which my idea visibly has no consequences at all. I can give an explicit rating between -5 and +5 (that's all about feelings though).

Conclusion

Here try to explain why you think the downsides are worth the upsides, and propose ideas that may be able to make the user experience even better if used with this one.

Sidenote : one may disagree with another, but in order to keep things constructive, i think one should comment the idea directly but keep the original description. One comment per person sounds fair, and people can then edit their own comments for each idea. Also, don't hesitate to give a mark to other ideas so that we can see which ideas have a consensus and which need debate. Thanks for reading till here ! (Template is very probably perfectible)

Ideas

If you think you have an idea that could address one of the above issues, please describe it and evaluate it's influence on all the listed issues. You can use the template for adding your own proposals .