I'm CCing -core on this as I think it's something worthy of getting
insights from people outside of just the security list as it would
affect portage and others...  If that was inappropriate, I apologize.

So on my way home tonight, I was thinking about some concerns regarding
security fixes and portage versioning.  AFAIK, the "official" policy
seems to be 'revision bump with the update.'  But what do we do if
multiple versions of a package are afflicted.  What if 1.2-r1 and 1.2-r2
are both inflicted, but r2 introduces new features in a patchset and is
not ready to be stable?  How do we handle this currently?  My instinct
on the matter would be:

r1 + fix -> r3
r2 + fix -> r4

But this seems a bit odd to me.  So an idea I had was to add an
aditional field to the portage version string to indicate a security
fix.. thus to use the recent xfree86 buffer overflows as an example
(xfree86-4.3.0-r3 had 2 security problems that were fixed in -r4 and
-r5) the fixes might have been released as xfree86-4.3.0-r3-s1 and
xfree86-4.3.0-r3-s2.

This would greatly ease confusion in cases like the one in the second
paragraph above if we have >=1.2-r2 in another ebuild's DEPEND.  As we
have it now, r3 (r1 + fix) would satisfy that DEPEND, but that's not
what was intended.  By using the -s# version suffix it keeps DEPENDS
straight and also aids people wanting to only update security fixes
rather than feature additions.

portage could implement 'emerge security' which only updates packages
that have a new -s# (security bump) available.