[Releasing] Security release process

[Thiago Macieira]

On sexta-feira, 8 de novembro de 2013 05:53:01, Heikkinen Jani wrote:
> 1.      What is that security issue to be fixed? I haven't notice any
> request etc related it?

The information will be shared when the public release of the security is 
made.

> 2.      What is the problem there. If we need to offer (or even release)
> security fix for 5.1.1 and call it 5.1.2 (5.1.1 + just that security fix)
> it should be pretty straight forward: current release branch is 5.1.1  so
> just add that one change there and re-tag it. Then we will have that 5.1.2
> in official release branch and users can take it if needed. And we can even
> release it ( of course we don't want to do it now but still it is
> possible). I have read mails related to these old/5.0 or old/5.1 branches
> and to be honest I don't fully understood role of those. I understood that
> those are used to integrate important fixes on to top of those old releases
> but still those aren't official release branches at all. So those shouldn't
> affect anything for our releasing process, right? If we have to "launch"
> (tag) security release 5.1.2, it will be done from official release branch
> by just adding that one fix there, tag it to 5.1.2 and that's it? And of
> course add that fix for those old/5.0 or old/5.1 branches as well. Then
> users can either use official 5.1.2 "release" or use unofficial version
> from old/5.1 branch and everybody should be happy, right?

It depends on what we will release as part of the security fix.

It can be:
a) full source and binary packages
b) source packages only
c) patch only

If we do a) or b), we then need to decide what to base on. It could be the 
previous tag or the current branch containing that tag (the next release). It 
would probably depend on how close to releasing that branch we'd be.

If we choose c) only, then that doesn't require branching off of the previous 
tag. Therefore, the patch should land in the branch it applies to.

According to the discussion I've just seen on IRC, the fix for this security 
issue will be released as patch only, applied to Qt 5.1. Therefore, the patch 
should land on old/5.1. According to the discussion on old/* patches, that 
means this patch must be in 5.2's tree first. So the security fix will come with 
a *patch*, not a SHA-1 to cherry-pick.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20131111/0b74c9e7/attachment.sig>