Re: [gentoo-dev] Re: Things one could be upset about
On Mon, Jan 26, 2015 at 8:21 AM, Duncan 1i5t5.dun...@cox.net wrote: The result of the current policy is that if you're waiting for the GLSA, unless it's _extreme_ priority (heartbleed level), on at least amd64, you're very often sitting there exposed for well over a week, and too often a month, after the fix is out there, actually installed on /my/ systems. And to me that's a game of Russian Roulette odds that I'm simply not willing to play. Agree. Honestly, I think we should really reconsider the current GLSA policy. I half-consider unsubscribing to them since they often come out weeks after a vulnerability is fixed on amd64, let alone discovered. If you're relying on glsa-check as the indicator as to whether you should update, then you're probably going to be vulnerable for weeks. I wonder if it would make sense to just send them out on first-fix, or even on stablereq. The main reason that I'd hold off on sending them out at first sign of vulnerability is that information on what versions are/aren't vulnerable is going to be hazy, and it won't have clear instructions on what to do. You might end up picking the wrong version to update to and then find yourself having to update again or downgrading or running ~arch because the package maintainer decided to do something different. By the time you have a stablereq things have settled down - maybe if a bug is found on another arch you might end up with a revbump, but that is going to be minor impact and anybody doing daily updates is going to get hit by that anyway. From a PR standpoint we'll be communicating to some users that they are vulnerable, and we haven't completely fixed the issue yet. I think we just need to reset expectations here. The fact is that today they're just as vulnerable, but we don't broadcast that. Sending out notice sooner will help out users who want to update based on GLSAs, and if there isn't a stable version yet the user can decide whether to just wait for testing or move ahead on their own. It just seems to me that the current approach of sending out GLSAs a month after the fix is available for 98% of our users makes them fairly unuseful. -- Rich
Re: [gentoo-dev] Re: Things one could be upset about
On Mon, 26 Jan 2015 09:20:30 -0500 Rich Freeman ri...@gentoo.org wrote: On Mon, Jan 26, 2015 at 8:21 AM, Duncan 1i5t5.dun...@cox.net wrote: The result of the current policy is that if you're waiting for the GLSA, unless it's _extreme_ priority (heartbleed level), on at least amd64, you're very often sitting there exposed for well over a week, and too often a month, after the fix is out there, actually installed on /my/ systems. And to me that's a game of Russian Roulette odds that I'm simply not willing to play. From a PR standpoint we'll be communicating to some users that they are vulnerable, and we haven't completely fixed the issue yet. I think we just need to reset expectations here. The fact is that today they're just as vulnerable, but we don't broadcast that. Sending out notice sooner will help out users who want to update based on GLSAs, and if there isn't a stable version yet the user can decide whether to just wait for testing or move ahead on their own. I do check also other sources of security related info and take measures if it affects me (update affected package, change configuration, ...). I should say earlier security updates instead of GLSAs which would be actually closer to reality. I agree that (unfixed) security issues should be communicated so we do not put false hopes to GLSA. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-dev] Re: Things one could be upset about
On Sun, 25 Jan 2015 04:29:43 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Alexey Mishustin posted on Sat, 24 Jan 2015 21:54:06 +0400 as excerpted: 2015-01-20 14:42 GMT+04:00 Róbert Čerňanský ope...@tightmail.com: I somehow thought that edit the overgrowing package.use file upon each emerge world annoys anyone the same as me. But for me this is one of the most useful and convenient options in Gentoo. Yes, I do edit package.use almost every emerge world. And I like to do it. And I don't want to delegate this right to any program - portage, or any other. Agreed that I don't want to (and won't) delegate that decision, but almost every emerge world? Not here. So ??? I do edit package.use (or my global USE flags) occasionally, but not as often as the above implies. What might I be doing different? Well, here's what I do: 1) I try to sync and update deep newuse @world once a week, tho sometimes it's every two weeks (but sometimes it's daily). I suppose if people only get to it every couple months, they'll have more [...] So maybe it's simply that I update frequently enough, tho I /do/ run ~arch as well, which changes much faster than stable, and I even run More frequent updates is most likely the reason that you do not have to edit use flags every time. Running testing perhaps does not increase the editing frequency because dependency changes are the same regardles of how many bumps a package has. For example in testing you'll get following updates of package foo: foo-1.1, ~foo-1.2, ~foo-1.3, foo-1.4. In stable, I would get: foo-1.1, foo-1.4. If dependency changes in 1.3, both of us could have to edit USE flags once. I update every 2-4 months (only GLSAs in between) therefore my experience is that I have to edit it every time (not for GLSAs of course). 2) My global USE= starts with -*. I got tired of worrying about what [...] 3) I don't normally distinguish between local and global USE flags. I normally treat them all as global and set them globally in my make.conf use file[1]. When I encounter a new USE flag, because of the -* in USE, it's off by default. If I decide I want it off, no problem, it's off. If I decide I want it on, I run an equery hasuse flag to see if any other package uses it. If nothing else uses it, [...] Similarly, if I encounter a new USE flag that's on already, obviously some other package I use is already using it and the entry is in my use file or it wouldn't be on already, due to the -* in that use file. That's a strong hint what I'm likely to want the default to be. If I decide I want it off anyway, I run an equery hasuse flag [...] So for all flags, if I want the default off, due to the -* in my use file, it's off. If I want the default on, it's in my use file, turning it on. 4) The result is that my package.use files contain ONLY non-default entries. More or less same here, except -* as the default. I trust developers that they are choosing wisely in profile and ebuilds. ;-) If not, I see it in emerge -av output anyway and can disable/enable particular flag. But generally I have vast majority of flags in make.conf and exceptions in package.use. When I set such an entry, I prefix a comment line with the date and an explanation of WHY the entry needs to be there, different from my normal default settings. Sometimes, it's due to a bug, and a couple versions later I can go thru and test with that entry commented, to see if the bug is fixed, yet. Other times it's due to a use-dep from some other package I have installed. Both qt and kde tend to have This where we get to the point. If you set USE flag because of a bug or because of dependency it is not because you *want to* but because you *have to* (or portage *needs to*). Therefore you need to add a comment WHY you did it. For example I have -doc in make.conf because I do *not want* docs globally. But I have 'dev-lang/python doc' in package.use because I develop in Python and *want* the documentation for it. Such entry does not need a comment, because I simply know what I want. Another example. I have -python globally and have been using app-mobilephone/gammu. Now I want to emerge app-mobilephone/wammu. But it needs +python for gammu, so I *have to* set 'app-mobilephone/gammu python' in package.use. In this case I also add a comment which explains the reason because it is not what *I want* it is what *portage needs*. Once this dependency is gone (either because wammu stops requiring it or I unmerge it) it is on me to detect it and remove the entry. So effectively I manage portage's stuff in my configuration file. Regardless of why it's there, however, because only non-default entries are in package.use, they're the obvious exception. You somehow do not distinguish between those two types of exceptions explained in examples above. And as exceptions, they don't tend to change that often. =:^) Generally, They might change as
Re: [gentoo-dev] Re: Things one could be upset about
On Wed, 21 Jan 2015 01:57:27 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Róbert Čerňanský posted on Tue, 20 Jan 2015 06:51:01 +0100 as excerpted: On Mon, 19 Jan 2015 20:51:31 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský ope...@tightmail.com wrote: From my point of view it would do much help if portage resolves USE dependencies automatically instead of telling the user to change USE flags manually (I am talking about bug #258371). This is only possible in carefully selected circumstances, and to get it to work more generally would require a lot of hinting from package maintainers. But portage already knows that. It tells the user which USE flags needs to be changed in order to emerge a package. It should just go one step further - to make the proposed change happen by itself. Actually, current portage (2.2.15 is what I have installed here ATM) does exactly that, making changes to the appropriate package.* files as necessary, mediated only by the usual CONFIG_PROTECT variables. No, no, no that is not the right solution. Portage should _not_ touch my precious config files crafted for many years. It should store the USE related dependencies info in its _internal_ structures (somewhere in /var/db/pkg I presume). Sorry I was not clear previously. Moreover it should be able to depclean them - revert the USE changes once the dependency is no longer needed (for example with new emerge option --use-depclean). Just like with standard package dependencies. Since /etc/portage is CONFIG_PROTECTed by default, these changes normally first appear in that feature's .* files, to be merged by the [...] tolerable. As others in-thread have stated, we don't believe that's something portage should be messing with. Totally agree, it should mess only with /var/db/pkg or so, not /etc. [... sniped great explanation of current testing portage behaviour in this regard; thanks for that, even though it is not what I crave for] Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
