Bug 1087859

Please use the following update submission link to create the Bodhi
request for this issue as it contains the top-level parent bug(s) as well
as this tracking bug.  This will ensure that all associated bugs get
updated when new packages are pushed to stable.

Please also ensure that the "Close bugs when update is stable" option
remains checked.

Bodhi update submission link:
https://admin.fedoraproject.org/updates/new/?type_=security&bugs=1081760,1087859

(In reply to Martin Prpic from comment #0)
> please ensure that it is only closed when all affected versions are fixed.

(In reply to Martin Prpic from comment #1)
> Please also ensure that the "Close bugs when update is stable" option
> remains checked.

Those instructions are in direct conflict. I'm choosing to ignore the first one but would like to see some improvement in the security bug workflow.

strongswan-5.1.3-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2014-5231/strongswan-5.1.3-1.fc20

(In reply to Pavel Šimerda (pavlix) from comment #2)
> Those instructions are in direct conflict. I'm choosing to ignore the first
> one but would like to see some improvement in the security bug workflow.

Hi Pavel,

These guidelines have been in effect for about five years and work fairly well. Many maintainers prefer to have a single bug for an issue rather than one bug per release. There clearly is some ambiguity in the wording, which is the side effect of the one bug per flaw approach. However, this has never caused any confusion for maintainers and you are the first one to bring this up. I don't think it's that much of a problem that we need to go to all the trouble with changing the whole workflow.

If you have a specific solution/idea to improve the current workflow, feel free to submit it to secalert.

(In reply to Martin Prpic from comment #4)
> (In reply to Pavel Šimerda (pavlix) from comment #2)
> > Those instructions are in direct conflict. I'm choosing to ignore the first
> > one but would like to see some improvement in the security bug workflow.
> 
> Hi Pavel,
> 
> These guidelines have been in effect for about five years and work fairly
> well.

As those guidelines contradict each other, you probably mean that they have been *partially ignored* for five years and it worked fairly well. I'm  sorry for reporting the logical contradiction.

> Many maintainers prefer to have a single bug for an issue rather than
> one bug per release.

When the maintainer wants to take the security bug seriously, he must create one errata/update per active Fedora release and it's pretty easy to include the respective bugzilla ticket in each errata.

I'm afraid the only reason maintainers want to have a single bug is that they don't care about tracking security issues in all active Fedora releases. Some of them probably don't care at all, others only care about the latest release.

> There clearly is some ambiguity

s/ambiguity/contradiction/

But you're right that contradiction leads to ambiguity and I don't even believe that all maintainers handle security updates in a uniform manner.

> in the wording, which is the side effect of the one bug per flaw approach.

I believe that it's a side effect of trying to make an illusion that the workflow ensures the single bug is only closed when it's fixed in all active fedora releases.

If both update requests are made by following the guidelines, the first update that gets stable closes the bug, right?

> However, this has never
> caused any confusion for maintainers and you are the first one to bring this
> up.

So I apparently should have stayed quiet as well.

> I don't think it's that much of a problem that we need to go to all the
> trouble with changing the whole workflow.
> 
> If you have a specific solution/idea to improve the current workflow, feel
> free to submit it to secalert.

I think you already discouraged me from posting anything by stressing that this hasn't been a problem for years, noone ever complained, maintainers want to have only one bug. Why should I try to help Fedora in ways that are apparently not welcome? Who cares about Fedora security anyway.

This is such a senseless argument.  I'm assuming you have nothing better to do with your time?  Where do you get the idea that no one cares about Fedora security?  How does _wording_ that everyone else understands, but you don't, imply _no one else_ cares about Fedora security?  What a silly assumption!

However, since I don't care to engage in this argument at all, I've made appropriate wording changes to our tools so that _future_ tracking bugs better explain things.  It will no longer state "please ensure that it is only closed
when all affected versions are fixed." as that seems to be your primary concern.

And no, we will _not_ be filing one bug per version of Fedora.  We used to do that.  Developers and maintainers hated it (and by that, I mean more than one).  We will not be upsetting the majority of other developers so that you can do things that you feel is proper (in direct opposition to everyone else).  If you feel so strongly about it, clone the bug.  There is absolutely nothing stopping you from doing so.  SRT, however, will continue to file exactly _one_ tracking bug when multiple versions of Fedora (or EPEL) are affected by the same flaw.

The wording also indicates that developers should fix _all_ affected branches at once, and yes there may be a race condition in that an update to Fedora 20 may close the bug because it hits stable before the update to Fedora 19 hits stable.  That is a very minor problem in our estimation.  Again, if you prefer, for _your_ bugs to have the extra overhead that everyone else is trying to avoid, clone the bug.  It really is that simple.

Now, given that this bug is about strongswan updates, and _not_ about the security workflow, if you wish to persist in this, file another bug.  In the meantime, please correct _this_ bug (I see an update for Fedora 20, but not one for Fedora 19).  Thank you.

strongswan-5.1.3-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Hi Vincent,

I don't think abusive words will be any helpful here. And I'm sorry you feel the need to make changes just to silence me, that certainly wasn't my intention. I admit that my last sentence wasn't particularly nice but this is the impression I'm getting from the whole process from handing over the strongswan security alert to the responses to my repeated report on the wrong wording. But as you say, my impression is certainly wrong.

> If you feel so strongly about it, clone the bug.  There is absolutely nothing
> stopping you from doing so.

It would be so much easier if Fedora made it officially known that this way is an allowed alternative. When I see the harsh responses to a mere suggestion of my little self, I don't want to imagine responses to intentionally diverging from the official workflow.

> there may be a race condition in that an update to Fedora 20 may close the bug
> because it hits stable before the update to Fedora 19 hits stable.  That is a
> very minor problem in our estimation.

Latest fedora release usually has a more active developer/tester community than the previous one. So more often than not, you get the bug report closed long before the fix is pushed to Fedora 19 stable while still officially supported.

I have no other chance than to accept that closing security bug reports before fixing them in all releases is an accepted fedora security policy.

> Again, if you prefer, for _your_ bugs to have the extra overhead that
> everyone else is trying to avoid, clone the bug.  It really is that simple.

As already stated, I don't want to later get bashed for diverging from the official security processes.

> Now, given that this bug is about strongswan updates, and _not_ about the
> security workflow, if you wish to persist in this, file another bug.

I do *not* want to persist this for the following reason:

1) The issue appears to be well known. It is up to you to decide whether you need a bugzilla ticket for it or not.

2) My feedback doesn't seem to be welcome at all. I have no reason to expect this to become any better by starting a ticket for it.

> In the meantime, please correct _this_ bug

 * I was ready to prepare the packages at the time of upstream release which unfortunately delayed by a couple of hours and therefore I was no longer available.
 * I prepared the packages and updates the next day and requested a push to f20, f19 and el6 testing immediately.
 * I requested stabilization of the packages as soon as I received an e-mail that it's possible.

I was still confused by the security bug workflow and I forgot to put the bug number in the f19 update. Sorry for that. Now that the update is stable, it no longer offers the *edit* button so I can't add the bug number. On the other hand, it's not so difficult to list the actual strongswan updates:

https://admin.fedoraproject.org/updates/search/strongswan

That said, I would *love* to use the "clone" workflow where each update has its own bug and apart from cloning and creating the updates, the system does everything for me and for my users who can then track the actual status of the security issue.