Re: berlios.de compromised since 2005
On Wed, 2010-01-13 at 12:33 -0600, Jon Ciesla wrote: > Seth Vidal wrote: > > Hi folks, > > This lwn article reports that berlios.de has been compromised for a long, > > long time. > > if you're on this list then you need to talk to upstream and find out if > > they have done an audit yet. You might consider doing an audit yourself, > > if you have the background to know what sort of things to look for. > > > > > Thanks, Seth. And if we don't, what's a good resource for security > auditing n00bs? Unfortunately if the attacker was really clever there is almost zero probability the backdoor can be spotted during a casual review of the code. So it would be found only by pure chance. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote: > > On Mon, 18 Jan 2010, Bill Nottingham wrote: > > > Ugh, this seems like it would just create a lot of make-work for the > > common case where packages *are* maintained. Perhaps only do this > > for packages that appear via some criteria (have not been built, have > > not been committed to, have lots of bugs with no response, etc.), but > > doing it for *every* package seems like overkill. > > > > Right - so maybe last check into devel branch since the last release of > the distro. > > If we do that check before the alpha release that should let us track down > awol maintainers and unmaintained pkgs pretty easily, I think. > > thoughts? I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote: > > On Mon, 18 Jan 2010, Tomas Mraz wrote: > > > I think there should be at least two conditions which would have to be > > fulfilled for the nagging bug to be created - the package was not > > touched by the maintainer during recent x months and at least one bug is > > opened not closed in the bugzilla on the package. > > > > I disagree about the bug being open. A lack of filed bugs could mean that > no one CARES about the pkg at all. And if we have pkgs which are not being > maintained AND no one cares enough to file a bug about then either they > are: > > 1. extraordinarily stable > 2. dead upstreams > 3. unmaintained > 4. unusued > > in ANY of those cases I'd want to start thinking about nuking the pkg from > fedora. So that means that for example for the openoffice.org-dict-cs_CZ package I'll get the nag bug report before each and every Fedora release? It is definitely not 4. however 1. and 2. apply to it. As this is just a czech spelling and hyphenation dictionary which is pretty good one and we do not have any alternative anyway I do not think that 2. matters much. OK, I think my next changelog entry in the .spec will be something like: - rebuilding just for the sake of not getting a nonsense bug report opened against the package -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote: > On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote: > > > > Imho the only real problem from your list is, if a package is > > unmaintained, because if it is maintained, the maintainer usually uses > > it, otherwise he would just drop it. If upstream is dead but the > > maintainer fixes bugs, when they are found, I do not see a problem, > > either. > > Often maintainers don't realize they have some of these packages, or the > maintainers have left the project. > > Even your most stable packages get touched nearly once a year due to > distribution changes. With a more active rpm upstream I suspect we'll > be seeing even more need to rebuild everything, at least once a year. > > In fact, if we were only checking once a year, I bet many of these > packages are going to get hidden behind the mass rebuilder. But these rebuilds are mostly automated ones by Fedora releng and as such not countable against the nag bug report. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Fri, 2010-01-22 at 12:41 +0100, Ralf Corsepius wrote: > Hi, > > On FC12 I found this: > > # ls /usr/bin/.*.hmac > /usr/bin/.fipscheck.hmac > /usr/bin/.ssh.hmac > > # rpm -qf /usr/bin/.*.hmac > fipscheck-1.2.0-4.fc12.x86_64 > openssh-clients-5.2p1-31.fc12.x86_64 > > Could somebody provide some insight what these files are (I guess some > checksums) and why they are being installed to /usr/bin? These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Fri, 2010-01-22 at 10:24 -0500, Przemek Klosowski wrote: > I don't believe so---it's not my line of business but I understand that > > - in some circumstances (government, regulated companies) encryption >must be certified to the FIPS 140-2 standard > > - on Linux encryption (https, ssh) is handled by OpenSSL, which went >through the FIPS certification process > > - one of the conditions of FIPS certification is a capability for >run-time consistency checks, hence the fipscheck package > > - the fipscheck package checks against the checksums stored in the >.XXX.hmac files, therefore those files are required if a system needs >to be FIPS-compliant. Yes, all the above is correct although it does not mean that the packages in Fedora are certified, they just have/use the changes which are necessary for certification. > Having said that, I don't understand how does this scheme prevent > someone from subverting the executable and creating a matching .hmac > file, so that the fipscheck fails to see the problem. I expect it's > handled properly but I don't know how. No, it does not prevent malicious attacker from subverting the executable. The integrity check prevents just inadvertent modification of the executables/libraries which contain the certified code. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Fri, 2010-01-22 at 17:08 +0100, Martin Langhoff wrote: > On Fri, Jan 22, 2010 at 5:04 PM, Tomas Mraz wrote: > > No, it does not prevent malicious attacker from subverting the > > executable. The integrity check prevents just inadvertent modification > > of the executables/libraries which contain the certified code. > > Like prelink? ;-) Yes, for example. That's why prelink must be disabled when the machine is running in the FIPS compliant mode. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Mon, 2010-02-01 at 14:00 -0500, Toshio Kuratomi wrote:
> On Mon, Feb 01, 2010 at 01:38:13PM -0500, Toshio Kuratomi wrote:
> >
> > 1) The present packages need to be fixecd. Sounds like fipscheck, hmaccalc,
> > and openssh. They are violating the FHS which is prohibited by the
> > Guidelines. Ralf, have you opened bugs?
> >
> > 2) We need to decide where to place the files. I don't know what uses them,
> > so I'm not entirely certain about this. Here's some suggestions:
> > * If each binary checks itself then %{_libdir}/%{name}/$PROGNAME.hmac
> > seems reasonable.
> > * If there are one of more programs (fipscheck?) that check the integrity
> > of other binaries then we probably want a directory structure that is
> > namespaced by itself and allows that other program to lookup the
> > checksum for the binary. Something like:
> > %{_libdir}/hmac%{_bindir}/$PROGNAME.hmac
> > %{_libdir}/hmac%{_sbindir}/$PROGNAM2.hmac
> >
>
> Caught j-rod and pjones on IRC who had the following insights:
>
> * Each binary is supposed to perform an integrity check of itself when it
> starts. So each binary needs to be able to find its hmac file.
> * hazy recollection is that fipscheck is meant to check the integrity of any
> binray with checksums. So we do need to use a directory structure that
> fipscheck can use to find the checksums.
>
> If I could get some input from the people who actually deal with fipscheck
> and this standard, that this is the way forward, I'll write up the
> Guidelines.
I am sorry, but I do not see a real need for special guideline for the
fipscheck checksums. The policy where these checksums should/will be
placed should be decided by the fipscheck package itself. Of course I
agree that the files must be moved from the current place to a
subdirectory under %{_libdir} especially for the checksums of the
binaries in %{_bindir} and %{_sbindir}.
There is still a slight problem with the library checksums especially
for the libgcrypt library which currently resides in /%{_lib}. This
means that if it looks for the checksum in %{_libdir}/fipscheck the /usr
might not be mounted during the checksum verification. The question is
whether the checksum in a hidden file in /%{_lib} violates FHS - in my
opinion it does not as this is still non-executable arch-dependent file
or whether we need to create a fipscheck subdirectory in /%{_lib} as
well.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Next privilege escalation policy draft
On Mon, 2010-02-01 at 15:47 -0800, Adam Williamson wrote: > Hi again, folks. Here is another draft of the privilege escalation > policy. This is the sixth draft (second to this list). Changes: one of > Kevin Kofler's queries alerted me to the fact that somehow all the > changes between draft 1 and draft 2 were lost from drafts 3 onwards, > d'oh :) They are restored, which addresses some points people raised > here that were previously raised and addressed on test list. I also > tried to clarify some more that the planned system whereby there'll be > an 'administrative users' group that the first account gets added to > automatically and to which other users can be added manually is OK, and > clarified the point KK misunderstood about what constitutes a 'policy > escalation mechanism'. > > again, comments are welcome! This is probably going to FESco next week, > not tomorrow, apparently they have a heavy schedule tomorrow. > > https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy What about all networking setup changes? Especially establishing a VPN connection can be used to tunnel all traffic through a rogue VPN server thus enabling attacker to monitor all the network traffic. The same holds for enabling WLAN interfaces if they are currently disabled. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Tue, 2010-02-02 at 21:04 +0100, Björn Persson wrote:
> Tomas Mraz wrote:
> > There is still a slight problem with the library checksums especially
> > for the libgcrypt library which currently resides in /%{_lib}. This
> > means that if it looks for the checksum in %{_libdir}/fipscheck the /usr
> > might not be mounted during the checksum verification.
>
> Will all programs that use Gcrypt stop working if the checksum is unavailable
> or can the library function without the checksum in an emercency recovery
> situation? Does anybody know?
The library will work fine and it will not compute the checksum at all
if the FIPS mode is not enabled which is the normal situation.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote: > On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote: > > > I am sorry, but I do not see a real need for special guideline for the > > fipscheck checksums. The policy where these checksums should/will be > > placed should be decided by the fipscheck package itself. Of course I > > As soon as multiple packages are affected, there should be a guideline > to document how something needs to be done to work, e.g. if someone > wants to package a new software that contains fips checksums. Huh, shouldn't reading documentation in fipscheck package be sufficient? Of course the documentation in the fipscheck package has to be changed to reflect the change. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora's ssh known hosts file
On Wed, 2010-08-11 at 01:55 -0700, Matt McCutchen wrote: > On Tue, 2010-08-10 at 09:07 -0600, Stephen John Smoogen wrote: > > On Sun, Aug 8, 2010 at 14:04, Matt McCutchen wrote: > > > On Thu, 2010-08-05 at 22:23 +0200, Till Maas wrote: > > >> Yes ssh is secure if used properly. To get the proper known_hosts entry, > > >> one has to download https://admin.fedoraproject.org/ssh_known_hosts btw. > > > > > > I'm very glad to see that Fedora provides such a list. I just installed > > > it on my computer (after filtering out hostnames not ending with > > > fedoraproject.org, for obvious reasons). > > > > > > Is it documented anywhere? For full security, every packager should > > > install it rather than allowing ssh to add host keys on first use. > > > > Well I am not sure that file would be all that useful as it contains > > lots of hosts a packager would not get to AND could conflict with > > other networks as it contains a lot of 10.X.X. and 192.X.X. ips. > > Then let's post an excerpt that would be useful to packagers. > > > It also gets updated from time to time as we rebuild hosts. > > That just speaks to the need for better tooling to maintain personal > known-hosts files, or for Fedora to operate an ssh certificate > authority. > > It appears that the ssh folks rejected X.509 out of disgust for the > public CAs, found themselves left with no solution at all to > authenticate hosts the first time, and are now reimplementing it > incompatibly. The man page claims the ssh implementation is "much > simpler" -- perhaps, but it won't integrate with X.509-based systems and > will be playing catch-up on features for a while. CRLs or OCSP, anyone? > > A thread from 2002 with some frank discussion that is still valid now: > > http://marc.info/?t=10117975211&r=1&w=2 The PKI is unfortunately hopelessly broken deep in its concepts. See for example here: http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1360143,00.html The DNSSSEC is much more reasonable way to go. But we are getting off-topic here. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Sat, 2010-08-14 at 19:57 +0200, Martin Sourada wrote: > On Sat, 2010-08-14 at 19:05 +0200, Kevin Kofler wrote: > > * Version updates, the very ones you complain about, brought that 4.0 up to > > 4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to F9's > > EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually one of > > the > > stablest Fedoras I used. (For example, F10 had issues with my hardware's > > ALSA driver affecting PulseAudio, F11 with the graphics driver.) > > > Well, the problem was that you pushed KDE 4.0 in the first place. Given > the state of things, you had very *strong* reasons to update to KDE 4.1 > and 4.2. And yes, pulseaudio was IMHO pushed one release earlier than > would be ideal as well... But note, that nothing in the Fedora update policy changes would prevent from the same push during the _development_ phase either. So you might be dissatisfied with the KDE-4.0 in F9 but this can happen with other packages or package stacks in new Fedora releases regardless of the update policy changes. So it is completely irrelevant to the debate here. And actually with the 'conservative update' policy once something like KDE-4.0 is in the _final_ release of a Fedora, it will have to stay there till the EOL of the release. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Tue, 2010-09-21 at 15:47 -0600, Kevin Fenzi wrote: > Greetings. > > I'd like to ask for feedback and helping cleaning up an updates policy > draft page: > > https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft > > How can we clarify the language or the layout of the page to be more > clear? Are there places that it could be more like the existing package > update howto page? Could we be more detailed about what bodhi enforces > and whats just good practice? > > Are there other exceptions cases that could be covered that you can > think of? > > NOTE that this is a draft. I'd like constructive feedback. > If we can get something that looks ok by next week, FESCo would like to > approve this and put it in place. > > Please do try and keep technical and constructive in replies, pretty > please? With a cherry on top? - Avoid changing the user experence if at all possible. - this is too strong condition. In some cases fixing a bug might inevitable change the user experience and in some cases for example the user experience might be just severally improved with the new release. So IMO this should be reworded with much less strong wording such as 'Avoid major changes and worsening the user experience if at all possible.' This example is IMO wrong: - WebKit requires an update to solve a security problem. This requires updating Midori to a version with some minor menu layout changes. This would be a judgement call based on how intrusive the changes are (removing the File menu would be rude, but moving the plugin configuration menu item would be acceptable). In this case even major changes in user experience are justified - knowingly insecure web browser just should not be used. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, 2010-09-22 at 12:48 +0200, drago01 wrote: > On Wed, Sep 22, 2010 at 12:35 PM, Tomas Mraz wrote: > > On Tue, 2010-09-21 at 15:47 -0600, Kevin Fenzi wrote: > >> Greetings. > >> > >> I'd like to ask for feedback and helping cleaning up an updates policy > >> draft page: > >> > >> https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft > >> > >> How can we clarify the language or the layout of the page to be more > >> clear? Are there places that it could be more like the existing package > >> update howto page? Could we be more detailed about what bodhi enforces > >> and whats just good practice? > >> > >> Are there other exceptions cases that could be covered that you can > >> think of? > >> > >> NOTE that this is a draft. I'd like constructive feedback. > >> If we can get something that looks ok by next week, FESCo would like to > >> approve this and put it in place. > >> > >> Please do try and keep technical and constructive in replies, pretty > >> please? With a cherry on top? > > > > - Avoid changing the user experence if at all possible. - this is too > > strong condition. In some cases fixing a bug might inevitable change the > > user experience and in some cases for example the user experience might > > be just severally improved with the new release. So IMO this should be > > reworded with much less strong wording such as 'Avoid major changes and > > worsening the user experience if at all possible.' > > Define "worsening" being different by itself is "worsening" for a lot of > people. It's clear that this cannot be a hard rule if we do not want to make Fedora ultra-conservative distribution. There are much better choices for ultra-conservative users. > > This example is IMO wrong: > > - WebKit requires an update to solve a security problem. This requires > > updating Midori to a version with some minor menu layout changes. This > > would be a judgement call based on how intrusive the changes are > > (removing the File menu would be rude, but moving the plugin > > configuration menu item would be acceptable). > > In this case even major changes in user experience are justified - > > knowingly insecure web browser just should not be used. > > That isn't any different than the firefox example on the page i.e > already covered. Yes, and that's the reason the example is wrong and it should be removed. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, 2010-09-22 at 16:09 +0200, drago01 wrote: > On Wed, Sep 22, 2010 at 3:34 PM, Tomas Mraz wrote: > > >> > This example is IMO wrong: > >> > - WebKit requires an update to solve a security problem. This requires > >> > updating Midori to a version with some minor menu layout changes. This > >> > would be a judgement call based on how intrusive the changes are > >> > (removing the File menu would be rude, but moving the plugin > >> > configuration menu item would be acceptable). > >> > In this case even major changes in user experience are justified - > >> > knowingly insecure web browser just should not be used. > >> > >> That isn't any different than the firefox example on the page i.e > >> already covered. > > Yes, and that's the reason the example is wrong and it should be > > removed. > > Not sure I follow you here ... you point out a problem and a solution > which is _exactly the same_ as the people who drafted the proposal > though about and now you say "it is wrong and should be removed". I say that the example of Webkit should be removed because if it is not possible to backport the security patch and due to the version update Midori has to be updated to a new version regardless of the changes of user experience. The part of the example "judgement call based on how intrusive the changes are" does not make any sense. We just cannot keep the old insecure version regardless on how intrusive the changes are. > What do you propose instead? Shipping insecure browsers? Let me quote > you "knowingly insecure web browser just should not be used." > > In case you didn't get what the example is trying to say "in such > cases changes like that are justified" . No, it doesn't say that, quite opposite of that. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, 2010-09-22 at 10:04 -0500, Bruno Wolff III wrote: > On Wed, Sep 22, 2010 at 17:01:02 +0200, > Tomas Mraz wrote: > > I say that the example of Webkit should be removed because if it is not > > possible to backport the security patch and due to the version update > > Midori has to be updated to a new version regardless of the changes of > > user experience. The part of the example "judgement call based on how > > intrusive the changes are" does not make any sense. We just cannot keep > > the old insecure version regardless on how intrusive the changes are. > > Security isn't binary. It may be that a security update addresses an issue > that can not happen in normal cases. It might be reasonable to just document > the cases where there is a problem so as to warn people not to do that. Of course, the issue might be very minor, but in that case it is not a "judgement call based on how intrusive thec changes are" but "judgement call on whether the pros and cons of doing the update are significantly in favor of pros" -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, 2010-10-01 at 14:51 -0400, Orcan Ogetbil wrote: > On Fri, Oct 1, 2010 at 1:28 PM, Bill Nottingham wrote: > > Orcan Ogetbil (oget.fed...@gmail.com) said: > >> What I am trying to say is, a redesign of an interface _usually_ have > >> valid reasons. Those users who don't want their menu items moving > >> around want to live like automated machines. Forbidding such changes > >> promotes lazyness. > >> > >> If the update removes features that existed in previous version, that > >> is another story. I support you forbidding this type of change. > >> > >> But I really don't buy this "users shouldn't be disturbed by moving a > >> button from left to right". If the user is disrupted to what they are > >> used to, he needs to learn not to (be disrupted). Do we really want to > >> serve a closed-for-learning community? :( > > > > It's restricting the arbitrary application of change to the user to > > times when they are well able to deal with it. If I'm running F-13 > > and trying to create a slide deck, and run into a crash, I want the > > update for the crash to just fix that crash. Not fix that crash and > > reorganize the slide interface so I need to relearn it for the slides > > I'm in the middle of. If this change is restricted to the next > > major release, I'm expecting some amount of change, and therefore are > > better able to process it, we're better able to document it, and so > > on. > > > > Taking your suggestion to its extreme, we should promote learning and > > resist automaton behavior by randomizing the menus at each click, changing > > the default MTA once per release, and so on. > > > > Random changes are different than planned-by-upstream changes. I don't > think I would like to have randomized changes. But I am all in for > planned changes that people thought about. > > Our views are very very different. But I don't need to reiterate my > opinions. I am sure you got them. +1 Usually upstream does not push random changes - usually the changes are useful in some way and improving user experience. If the upstream is so stupid to push really random changes in their minor releases (I do not advocate here major releases updates from upstream in released Fedoras) then probably the package should not be part of the Fedora at all or the package maintainer in Fedora should be able to backport individual patches for bug fixes. But disallowing any changes in user experience and minor updates from upstream in released Fedoras is unreasonably strict. Also when getting back to the infamous KDE 4.0 in Fedora 9 - when the decision was made to ship KDE 4.0 (regardless of whether it was bad or not) in the final release - it would be really stupid to disallow updating KDE packages to new upstream versions that changed user experience (mostly by improving it). -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On Wed, 2010-10-06 at 16:41 +0200, Ralf Corsepius wrote: > On 10/06/2010 04:08 PM, Michal Schmidt wrote: > > On Wed, 06 Oct 2010 15:26:59 +0200 Ralf Corsepius wrote: > >> On 10/06/2010 02:49 PM, Matej Cepl wrote: > >>> Nonsense, trademarks exists to protect users and to avoid living off > >>> somebody else brand recognition. > >> > >> I disagree - trademarks exist to protect the manufacturer from > >> loosing profits because of their products being copied. > >> > >> Ask Adidas or Nike why they sue Chinese manufacturers and you'll see. > >> They'll tell you that they loose money because of being copied. > > > > Of course. But there's in fact no disagreement, only looking at > > different aspects of the same thing. > > > > Why do you think the copying takes place? Because the companies have > > built a good reputation and brand, allowing them to increase profit. > > > > Good quality => good reputation => solid brand => better profits. > > I am not disagreeing that restrictive trademarks, patents, restricive > license etc. all make sense in the commerical world. > > However, this here is Fedora, a project that once was aiming at > "Freedom" - As trivial as it is, restrictive trademark policies simply > do not fit into this philosophy. I give +1 to this. On the other hand Fedora also is (was?) a project where individual package maintainers had the biggest influence on what packages ship if they do not cross some fundamental legal limits. This changed in many ways recently and the restrictions and requirements are more and more technical, not just legal, and even controversial. The problem here really is that some "not so important?" projects are forced to accept all the restrictions and requirements and other "more important?" projects get a free pass from them. This is unfortunate and it does not improve the spirit of the package maintainers. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On Tue, 2010-10-26 at 00:28 +0200, nodata wrote: > Hi, > > I'm concerned about the default behaviour of mounting encrypted volumes. > > The default behaviour is that a user must know and supply a passphrase > in order to mount an encrypted volume. This is good: know the > passphrase, you get to mount the volume. > > What I am concerned about is that the volume is mounted for _every_ user > on the system to see. > > I've filed a bug about this, and it got closed: > https://bugzilla.redhat.com/show_bug.cgi?id=646085 > > I'm quite in favour of secure by default. In the worst case, the > mountpoint would have permissions set to read access to all if you tick > a box. > > Thoughts? > This could be achieved by using pam_namespace to separate the namespaces of the logged-in users and mounting the encrypted volume as private into the namespace. However it also means that when the user is simultaneously logged in twice, he will not be able to access the encrypted volume in the second session either. It also means that the process that mounts the volume must run in the namespace of the user's session (setuid helper would be needed instead of using system service to mount the volume). -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: new cg-manager gui tool for managin cgroups
On Thu, 2011-07-21 at 10:20 -0400, Jason Baron wrote: > Hi, > > On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote: > > On Wed, 20.07.11 15:20, Jason Baron (jba...@redhat.com) wrote: > > > > Heya, > > > > > The memory and cpu share controllers are currently supported (I simply > > > haven't > > > gotten to supporting other controllers yet). One can add/delete cgroups, > > > change > > > configuration parameters, and see which processes are currently associated > > > with each cgroup. There is also a 'usage' view, which displays > > > graphically the > > > real-time usage statistics. The cgroup configuration can then be saved > > > into /etc/cgconfig.conf using the 'save' menubar button. > > > > How does it write that file? Does the UI run as root? That's not really > > desirable. It's not secure and it is cumbersome to mix applications > > running as differnt users on the same session and one the same X > > screen (since they cannot communicate with dbus, and so on). > > Right, as Dan Walsh, mentioned I need to separate this into two parts - > the front end UI and a backend communicating via DBUS. This is had been > a todo item. Note that in case the services that the backend provides for the GUI are really powerful there is no real security benefit in separating the GUI and backend. I am not sure that a cgroup manager would be such case though. For example if the backend service is "interface to enable and configure various network based authentication services" as it would be in case of authconfig if it was split into GUI and backend, then you can easily instruct the backend to authenticate against a network service that will give you root user with no password. So we would have to trust the user X session that is the authconfig frontend running in anyway. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15: ugly behavior of "df"
On Thu, 2011-07-21 at 23:15 +0200, Reindl Harald wrote: > > Am 21.07.2011 23:04, schrieb Karel Zak: > > On Thu, Jul 21, 2011 at 08:09:08AM -0400, Genes MailLists wrote: > >> /proc/mounts does not seem to distinguish bind mounts - so this may > >> have to be a kernel change and perhaps adding /proc/mounts/bind and > >> moving bind mounts 1 level down - this is not an area I know a lot about > >> however, so I'll leave this to the real experts. > > > > I've already talked about it in this list... "bind" is operation, not > > state of any mountpoint. Something like /proc/mounts/bind does not > > make sense from kernel's point of view > > sorry but if i get borked as suer with endless lists in "df" > and useless warnings while callign "df" the kernels point > of view does not matter for me! > > you want a example of the real world - here it is: > > * openssh / sftp > * chroot > > Match User anyuser > ChrootDirectory /some/mepty/folder > > * to use sftp as ftp-replacement you need bind-mounts > * create 20 empty folders > * every of this gets a bind-mount to the users webspaces > > having 100 user with 5 subfolders in F15 means you > see a list with 500 entries calling "df" in F15 > > is this funny? > no it is not! But it still does just mean that df must be fixed, not that /proc/mounts/bind would make any sense or even if patched somehow would be acceptable into the kernel. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On Tue, 2011-07-26 at 13:59 -0600, Jerry James wrote: > I just did a "package-cleanup --orphans" on my Rawhide machine to see > which of the just-blocked packages are installed there. To my > surprise, I got this: > > # package-cleanup --orphans > Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit > [snip stuff that I need to take care of] > rpm-4.9.1-2.fc16.x86_64 > rpm-build-4.9.1-2.fc16.x86_64 > rpm-build-libs-4.9.1-2.fc16.x86_64 > rpm-devel-4.9.1-2.fc16.x86_64 > rpm-libs-4.9.1-2.fc16.x86_64 > rpm-python-4.9.1-2.fc16.x86_64 > # repoquery rpm > rpm-0:4.9.0-10.fc16.x86_64 > > Was this intentional? Yes, rpm-4.9.1 has seriously broken rpmbuild process. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On Tue, 2011-07-26 at 13:24 -0700, Jesse Keating wrote: > On 7/26/11 1:14 PM, Michael Schwendt wrote: > > Yes, It got untagged. See last week's thread on this list: > > Subject: rpm builds failing with "Installed (but unpackaged) file(s) found" > > I thought there was a hard rule about not having nvrs go backwards, and > if a bad build was put out, it should be fixed with epoch or other such > NVR things to make sure the upgrade path continues. (that is once a > build makes it out in the nightly repos) I do not think it was so hard rule for rawhide - it depended on various things whether it was needed or not. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User-level instance of /bin in PATH
On Wed, 2011-07-27 at 00:01 -0400, Braden McDaniel wrote: > On Tue, 2011-07-26 at 08:45 -0430, Robert Marcano wrote: > > On 07/26/2011 08:36 AM, Genes MailLists wrote: > > > On 07/26/2011 08:03 AM, Misha Shnurapet wrote: > > >> 26.07.2011, 18:34, "Andrew Haley": > > >>> On 26/07/11 10:22, Misha Shnurapet wrote: > > >>> > > >>>> Since F15 ~/bin has been added to PATH, and commands that are > > >>>> supposed to run user scripts will work without changing into that > > >>>> directory. Meanwhile, ~/.local/bin isn't used. I'd like to propose > > >>>> that it is also added because technically it is ~/bin's brother. > > >>> > > >>> I've never heard of ~/.local/bin . Are there many people who use > > >>> this? ~/bin is common. > > >> > > >> ~/.local/bin has been there by default. > > >> > > >> Unlike ~/bin, which is in PATH though not even created. > > >> > > > > > >Where in the path do the user 'bin' elements appear in the path? > > > > In /etc/skel/.bash_profile they are added to the end and I think that is ok > > > > PATH=$PATH:$HOME/.local/bin:$HOME/bin > > > > Never knew about ~/.local/bin my .bash_profile is really old from the > > time where the default was only ~/bin > > Can someone explain (or point to) the rationale appending these to PATH > rather than prepending them? I would have expected user binaries to > supersede system ones. Although there is probably only a small number of security vulnerabilities of user applications that would allow just creating and writing new files on a file system, nevertheless there can be some. The attacker could then create any binary that users usually run and get a full control of the user's account easily this way. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On Wed, 2011-07-27 at 11:03 +0200, Michael Schwendt wrote: > On Tue, 26 Jul 2011 14:42:09 -0700, TK (Toshio) wrote: > > > On Tue, Jul 26, 2011 at 01:24:58PM -0700, Jesse Keating wrote: > > > On 7/26/11 1:14 PM, Michael Schwendt wrote: > > > > Yes, It got untagged. See last week's thread on this list: > > > > Subject: rpm builds failing with "Installed (but unpackaged) file(s) > > > > found" > > > > > > I thought there was a hard rule about not having nvrs go backwards, and > > > if a bad build was put out, it should be fixed with epoch or other such > > > NVR things to make sure the upgrade path continues. (that is once a > > > build makes it out in the nightly repos) > > > > > Yep. You are correct. If I'm doing proper forensics of fesco meeting notes > > and tickets and google searches of the wiki, this policy was approved twice > > by fesco but didn't get documented either time: > > > > https://fedorahosted.org/fesco/ticket/96 > > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313 > > > > The original proposal fell out of the no frozen rawhide FAD if I remember > > correctly. > > Ticket 96 is very imprecise, unfortunately. > > There is a big difference between "a package going backwards in its EVR > and staying there" and "a package getting untagged because it breaks koji > buildroot and with the plan to go forward in EVR as soon as the bug is > found and fixed". > > In this case, the bad rpm-build broke koji builds, and since Rawhide > may eat babies, it can happen that Rawhide users need downgrade manually > while they have to wait for the fixed rpm-build. +1, this should be only temporary breakage, although the fix is unfortunately not there yet. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide openssh-server update kills sshd
On Wed, 2011-07-27 at 09:33 -0500, Bruno Wolff III wrote: > One thing to watch out for is /var/empty. I have had to manually recreate > /var/empty and /var/empty/sshd to get the server to work again. This > might be related to the recent rpm issue, but I am not sure about that. Yes, it is related to the recent rpm issue and unfortunately to another issue that rpm when upgrades a package that had // to a package that has / it happily deletes the directory if it is empty on cleanup of the old package. And the same happened when update was the other way when the openssh rpm got broken by the rpm build. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PokerTH orphaned
On Mon, 2011-08-01 at 10:29 -0700, Ryan Rix wrote: > On Mon 1 August 2011 11:46:00 Jussi Lehtola wrote: > > Hi, > > > > > > I've just orphaned PokerTH, since I'm trying to free myself some time > > and I don't use it myself. > > > > PokerTH does not currently build on rawhide, since OpenSSL support has > > been dropped from GnuTLS a week ago (BZ #726697). Getting it to build > > again would then require building against OpenSSL (and asking upstream > > for a GPL license exception), or shipping a private copy of GnuTLS. > > I picked up rawhide through F-14. If I cant get this building, I'll orphan it > again in a week's time. Shipping a private copy of GnuTLS would have to get an exception I do not think such exception should/would be granted. I can only recommend you to look at the NSS OpenSSL compatibility support library and patching PokerTH to use it instead of the GnuTLS. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PokerTH orphaned
On Tue, 2011-08-02 at 07:51 -0500, Jason L Tibbitts III wrote: > >>>>> "HdG" == Hans de Goede writes: > > HdG> Hi,HHdG> Tomas has chosen to fix this problem by simply disabling the > HdG> openssl compat part of gnutls (which as the above bug shows is > HdG> broken by design) given that only 3 apps use this, this seems like > HdG> a sane choice to me. > > Except, of course, it appears that someone completely forgot to contact > the people who maintain those applications. That's not how it's > supposed to work. Given that it's only three applications, that should > have been pretty easy. The point is that it's not OK to think "we're > only screwing three maintainers; it's OK to do this without actually > talking to them." > > My upstream (zoneminder) explicitly removed openssl support because of > the licensing issues. It can still be made to work, but of course that > violates their license and I can't imagine that at this point they're > going to just change their license to allow us to ship the software. Of > course I'll try, but in the meantime I certainly can't actually build > the software in Fedora. The problem is I tried repoquery against the rawhide repository before the disabling and either the repository was somehow broken or I made some mistake because the repoquery returned empty results. That's why I thought that there is no package depending on the libgnutls-openssl anymore and so I dropped it. But I really do not plan to add it back because upstream does not care about it and it seems to be left in the experimental state forever. I do not think any other software should depend on it for the SSL support. Either rewrite the SSL support to use the native GNUTLS API, or use the NSS OpenSSL compatibility layer which is written in such way that it does not conflict with the native OpenSSL libraries. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On Wed, 2011-08-03 at 22:12 -0400, Simo Sorce wrote: > On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote: > > Enabling updates-testing by default for Branched was a very stupid > > decision. > > This should be reverted. updates-testing should NEVER be enabled by > > default. > > > > We should instead focus on getting stuff out to stable faster. In > > particular, why not allow direct stable pushes (without any karma) > > for > > branched-but-unreleased versions? > > +1 +1 from me as well at least up to the beta release. Between beta to pre release I'd require just 1 karma from non-proventester for critical path. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for today's FESCo meeting (2011-08-15)
I am apologizing for the late meeting invitation. Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = no tickets = New business = no tickets = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Tomas Mraz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Meeting minutes/summary for 2011-08-15 fesco meeting
rawhide/f16? or ? 17:50:20 nirik: Only F15 17:50:30 ah. 17:50:48 F14 had 0.9.8 which was unaffected, and F16 had 0.9.11 (and recently 0.9.13) which contained the fix 17:50:52 I'd suggest trying to rebuild them all and add them in one update so they all push out at once with no dep issues. 17:51:28 nirik: Well, the first problem with that is that I don't own all the packages that depend on it 17:51:38 (I think I may need to apply for provenpackager) 17:51:48 yeah, might be good... 17:52:00 The second problem is that, last I checked (Thursday) the buildroot overrides didn't take provenpackager into account 17:52:02 sgallagh, now it would be handy to be a provenpackager/sponsor automatically :) 17:52:27 heh 17:52:30 afaik you can only ask for br overrides for things you're explicitly on the acl for, yeah 17:52:39 sgallagh: they don't... yeah. it's a bug. 17:52:48 Hopefully a fixed bodhi soon. 17:53:14 BZ for reference: https://bugzilla.redhat.com/show_bug.cgi?id=730014 17:54:35 sgallagh, what do you need from FESCo? Any proposal? 17:54:38 So without that fix, I probably need to rely on the maintainers of the dependent packages to push their updates with me 17:55:09 t8m: Am I mistaken that the best move here would be a "mass rebuild" branch (for very loose definition of "mass")? 17:55:15 yeah, or a provenpackger to assist. 17:55:45 I propose we make sgallagh a provenpackager. 17:55:46 t8m: I guess my first step should be requesting provenpackager. 17:56:09 our process calls for asking for feedback from sponsors for a week. ;) 17:56:20 * sgallagh chuckles 17:56:23 meh ;) 17:56:35 That's fine, as I'm going to be at LinuxCon, I won't have time to fix this before next Monday anyway 17:57:04 sgallagh: great, so you can create provenpackagers request ;-) 17:57:19 Will do 17:59:19 * nirik nods. Sounds good. Anything more? 17:59:20 sgallagh, as for a special mass-rebuild branch - I do not think it is necessary in this case 18:00:31 https://fedorahosted.org/fesco/ticket/660 18:01:16 If there is nothing else to discuss I'll close the meeting in 2 minutes. 18:03:26 #endmeeting -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Patching config files (or not)
On Fri, 2011-08-12 at 18:50 +0200, Jos Vos wrote: > Hi, > > Should configs files of a package be patched to have settings that > make it work more or less out of the box (as far as possible, some > setting like DB access etc. just can't be filled in in advance)? If possible and does not really need individual configuration by a system administrator, yes. > I came across a package that defines to use "nogroup" in its config > file as effective group (Fedora has no "nogroup", but has group "nobody") > and defines to put a pid file in /var/run (which fails, as it appears to > do that as nobody/nobody when running). > > Should this config file have been patched to use "nobody" as group and > should the package (for example) include a package-specific directory > below /var/run to put its own pid file in (and patch the config file > to use this directory for pid files)? It is generally insecure to share groups/uids between different system daemons. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 2011-08-25 at 10:24 -0400, Paul Wouters wrote: > On Wed, 24 Aug 2011, Ian Pilcher wrote: > > > On 08/22/2011 06:35 PM, Paul Wouters wrote: > >> If it could also not grab port 0.0.0.0:53 in the future, that would be > >> great. I'd like to work with whichever libvirt developer takes this > >> package on. > > > > Are you talking about dnsmasq or the way that libvirt uses dnsmasq? > > I am talking about livirtd's usage. It's confusing and bad for various > reasons, but > most importantly: > > 1) Prevents other DNS resolvers from listening (eg DNSSEC aware ones) > 2) "service dnsmasq stop" fails because it is not started as a regular service > > > > When libvirt starts dnsmasq, it tells it to ignore the configuration > > file and passes all of the parameters on the command line. If you want > > dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll > > have to take that up with the libvirt developers. > > Here the issue is: > > 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still > configures and starts dnsmasq (at least on F14 using virt-manager) > (eg I have a /28 bridges to eth1 with static IPs, I don't want it) On a non-bridged setup it listens just on the virbr private interface address so at least in such setups it does not conflict with bind running as a local caching nameserver. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 13:41 +0100, Matthew Garrett wrote: > On Tue, Aug 30, 2011 at 06:50:11AM -0500, Bruno Wolff III wrote: > > On Tue, Aug 30, 2011 at 03:33:04 +0200, > > Kevin Kofler wrote: > > > > > > No, it means that (unless this was recently fixed) you have to modprobe > > > it > > > manually (e.g. from rc.local) because nothing bothers trying to modprobe > > > it > > > for you anymore. IMHO, this is really broken, but the bug reports about > > > it > > > were ignored or declared NOTABUG. > > > > There was significant discussion about this issue on the mailing lists > > and Kyle thought he had a good solution to having the floppy drive > > recognized when it was there and not adding long delays to the boot up > > for people with incorrectly configured (your supposed to disable the floppy > > drive in the bios when you don't have one) or broken bios. I am not sure > > what happened with the implementation of the solution. > > ACPI turned out to be full of lies. The real problem is that machines > will report a floppy controller even if they have no floppy drives > attached, and the ACPI function that's supposed to return a list of > drives usually returns a mixture of falsehoods and untruths. Merely > havig a floppy controller is enough to get the floppy driver loaded, > which then hangs for ages looking for a drive. That seems like a clear opportunity to add a simple "configure legacy hardware" button to anaconda, that would do the modprobe floppy/gameport etc. stuff so it is loaded. Perhaps there could be switches: I have these legacy hardware: Floppy disk Analog joystick whatever -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, 2011-08-30 at 17:11 +0100, Matthew Garrett wrote: > On Tue, Aug 30, 2011 at 11:49:37AM -0400, Bill Nottingham wrote: > > Matthew Garrett (mj...@srcf.ucam.org) said: > > > On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote: > > > > Or modules-load.d if you want to force load a module. > > > > > > Oops. Yes, that's what I meant. > > > > Is there a reason that (at least for the one case) this wouldn't just > > go in the joystick package? > > Joystick seems to be part of the default install (it handles USB devices > as well as legacy ones), and we probably wouldn't want this by default. Yes, but it could be a subpackage of it. No need to create new source package for just this simple configuration file. Tomáš Mráz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On Wed, 2011-09-21 at 12:45 +, "Jóhann B. Guðmundsson" wrote: > On 09/21/2011 10:21 AM, Adam Tkac wrote: > > Another argument for enforcing DNSSEC is that in future (well, I believe > > :) ) DNS will be used as storage for X.509 certs, SSHFP records and > > other stuff. If we adopt "leisure" approach (automatic disabling of > > DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC) > > then we can end in the same situation as we are currently with X.509 > > certs. Everyone will simply click on "disable DNSSEC" button or, when > > MITM attack will be in progress, DNSSEC will be automatically disabled. > > This will degrade DNSSEC benefits. > > Beside the obvious design flaws in dnssec and in the long run they only > solve a part of the problem how can you even consider removing the > ability for disabling dnssec when implementing and deploying and running > dnssec increases the complexity times hundred and people and isp's alike > cant even implement and properly run a simple dns server as it is now? You probably did not understand the meaning of "removing the ability for disabling dnssec" in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec. Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted. Domains that are not marked as dnssec enabled (that should be the default for admins that are unable or unwilling to use dnssec on their domains) are not affected in any way. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo meeting agenda for 2011 Oct 10
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #667 Request to fix CRITPATH update process .fesco 667 #topic #663 Late F16 Feature Java7 .fesco 663 = New business = No new tickets since last FESCo meeting. = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo meeting (2011-10-10)
=== #fedora-meeting: FESCO (2011-10-10) === Meeting started by t8m at 17:01:11 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-10-10/fesco.2011-10-10-17.01.log.html Meeting summary --- * init process (t8m, 17:01:41) * #663 Late F16 Feature Java7 (t8m, 17:03:08) * #667 Request to fix CRITPATH update process (t8m, 17:07:20) * Waiting on stats on proventester karma in Bodhi (t8m, 17:10:41) * LINK: https://fedorahosted.org/bodhi/ticket/642 (nirik, 17:12:30) * The update timeout for critpath packages still to be implemented in Bodhi - https://fedorahosted.org/bodhi/ticket/642 (t8m, 17:13:38) * Deferred to next week meeting (t8m, 17:15:40) * Fedora Engineering Services tickets (t8m, 17:16:05) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (t8m, 17:16:19) * Next week chair (t8m, 17:18:40) * The next week meeting chair is notting. (t8m, 17:20:15) * Open floor (t8m, 17:20:32) * PA update to 1.0 postponed to F17 - as per maintainer's decision (t8m, 17:30:07) * Discussion of Firefox extension updates after Firefox version update (t8m, 17:30:48) Meeting ended at 17:43:35 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * t8m (47) * nirik (33) * mjg59 (26) * sgallagh (12) * ajax (8) * pjones (8) * zodbot (6) * notting (6) * dbhole_ (4) * mmaslano (2) * cwickert (0) -- 17:01:11 #startmeeting FESCO (2011-10-10) 17:01:11 Meeting started Mon Oct 10 17:01:11 2011 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:13 Hi all. I won't be able to stay for the whole meeting. It is a holiday up here in Canada -- just came here to provide an update on #663 since I wasn't here last week. Rebuild for 663 are done according to rel-eng ticket 4932. I will be going through the list tomorrow to ensure that everything has indeed been rebuilt correctly. 17:01:27 #meetingname fesco 17:01:27 The meeting name has been set to 'fesco' 17:01:34 #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 17:01:34 Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:01:41 #topic init process 17:01:43 * nirik is here. 17:01:45 Hello all 17:01:47 hi 17:01:49 * notting is here. although i have to step out just before 2PM 17:01:58 hello. 17:02:02 * sgallagh is here but juggling many things at the same time 17:02:21 Hopefully we will be quick this time 17:03:03 We can start I assume 17:03:08 #topic #663 Late F16 Feature Java7 17:04:17 According to the dbhole's update above he still needs to check that the rebuild was complete. 17:04:33 .fesco 663 17:04:38 t8m: #663 (Late F16 Feature Java7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/663 17:04:55 Yes, it should be resolved. I just need to verify before closing the ticket 17:05:18 I think it's all done. 17:05:21 yeah 17:05:30 dbhole_, fine 17:06:36 OK, any comments? 17:06:52 * nirik has nothing more on this. 17:07:02 * dbhole_ doesn't either 17:07:04 I suppose we can move on. 17:07:20 #topic #667 Request to fix CRITPATH update process 17:07:22 OK. Thanks everyone! 17:07:31 .fesco 667 17:07:33 t8m: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667 17:07:47 I asked Luke about the stats on proventester 17:08:00 He said it should be easy enough to do, but I don't have them yet 17:08:02 I'll follow up 17:08:36 I also haven't heard on the ticket to allow the 2 week timeout. 17:08:36 Didn't we make a decision on this last week? 17:08:40 I can ask about that. 17:09:03 Hmm, no one ever sent out the minutes last week 17:09:05 also, we did have another proventester meetup... not sure we got very far, but we had various ideas. 17:09:20 sgallagh: uh, yes i did. 17:09:40 Message-id: <4e89f4d9.8010...@redhat.com> 17:10:13 think it was as a new thread start rather than a reply to agenda, but they were sent 17:10:38 true enough 17:10:41 #info Waiting on stats on proventester karma in Bodhi 17:10:48 Hmm, I didn't see it 17:11:48 nirik, where is the ticket for the bodhi changes to allow the critpath timeout? 17:11:52 so, I think we defer this topic again, and try and gather more info. 17:11:58 t8m: let me get a link, just a sec. 17:12:17 nirik, I agree 17:12:30 https://fedorahosted.org/bodhi/ticket/642 17:13:38 #info The update timeout for critpath packages still to be implemented in Bodhi - https://fedorahosted.org/bodhi/ticket/642 17:14:11 Anybody against deferring the ticket to the next meeting? 17:14:39 * nirik isn't 17:14:43 no 17:14:55 nope 17:15:10 sgallagh, the decision was only for the partial workaround anyway (the timeou
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 14:16 -0400, Simo Sorce wrote: > On Wed, 2011-10-12 at 13:04 -0500, Mike McGrath wrote: > > On Wed, 12 Oct 2011, Simo Sorce wrote: > > > > > On Wed, 2011-10-12 at 11:41 -0600, Kevin Fenzi wrote: > > > > On Wed, 12 Oct 2011 13:30:19 -0400 > > > > Jeff Layton wrote: > > > > > > > > > I have a question not covered here: I just changed my ssh key a week > > > > > or two ago in the wake of the kernel.org compromise... > > > > > > > > > > Is my new key sufficient? I really don't want to have to re-distribute > > > > > my key to all of the various servers again. > > > > > > > > Well, we talked about this some, but we don't have fingerprints from > > > > several weeks ago to check people against to confirm they uploaded a > > > > new key. > > > > > > > > Would it be possible for you to just make a new fedora only key? > > > > > > Can you stop asking useless security theater measures instead ? > > > > > > My ssh keys are fine and I see no reason to change them for you. > > > If all projects I participate in were to ask me to change my keys I > > > would end up with a mess of different keys for absolutely no reason. > > > > > > I have no problem with changing the password, but leave my ssh keys > > > alone, unless there is a real reason to ask people to change them. > > > > > > > Look at it this way, your keys and password may be fine. Can you say the > > same about every other Fedora contributor? It not, what criteria would > > you use to say who should and shouldn't change their passwords and keys? > > Given the way passwords are used I see no issue in asking them to be > changed, they are very easy to steal in our current system, so I don't > complain about that. > > Ssh keys are a different matter, they are generally much more secure as > they are not easily distributed or easy to steal, and changing them is > no assurance the new ones are not as compromised. (see previous mail) > > > Lots of people use and share keys across different projects. Lots of bad > > stuff is going down, we don't have much information on what's been > > compromised where, who or how. It might seem like theater to you. > > You're very in tuned with the feng-shui of security and you are probably > > fine. But not all of our contributors can say that. > > Storing a public key is not an issue, so the fact I use my key with > different projects has absolutely no bearing on my exposure, zero, > zilch. Unless I store my *private* keys on non-personal machines. > > The problem is that blindly changing keys if a contributor is being > careless accomplishes exactly nothing, and just burdens all careful > ones. > > If you have evidence of contributors being careless with SSH keys the > only recourse is to identify and educate the offenders requiring them to > change those keys and not have a 'hit 100 to educate 1' policy that > serves little or no purpose. +1^10 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 12:20 -0700, Adam Williamson wrote: > On Wed, 2011-10-12 at 21:07 +0200, Henrik Nordström wrote: > > ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath: > > > > > Lots of people use and share keys across different projects. > > > > There is no security issue in sharing kes across different projects, > > Sure there is. There's the exact same problem as using the same password > across multiple projects: if someone compromises the key they have > compromised all of those projects. If you use a different key for each > project, an attacker can only compromise one project with any given key. > Sure, ssh keys are much harder to compromise than passwords, but > _assuming a compromise has happened_ the consequences of using a single > key for everything are just as bad as using a single password for > everything. That's a nonsense. Simply said. If I have a properly generated random ssh private key with a strong passphrase that I never put outside of my workstations and safe backup media then there is no other way it can be compromised than to compromise my workstation. And in that scenario it surely does not matter whether I use single key for all the various projects or multiple keys each key for a single project. Of course if the public key algorithm (RSA or DSA) is broken such that the private key can be derived from the public one or from the signatures then it might make a slight difference. But that is currently not possible for keys >= 1536 or so bits even with large computing power. And if there was an easy way to break the public key algorithms many more things would be broken than just a single compromised SSH key. This is completely different from the password scenario where the storage and transport model of the password from the user to the server is extremely variable and might be quite insecure in some cases. The much better security of the SSH public keys is actually not coming from the fact, that they are "larger" and "random" but from the fact that they are misused much harder than the passwords. And Fedora account policy should reflect that and not blindly request changing SSH keys from people who keep them safe. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 15:43 -0400, Paul Wouters wrote: > On Wed, 12 Oct 2011, Kevin Fenzi wrote: > > > * DO verify ssh host keys via dnssec protected dns. ( .ssh/config: > > "VerifyHostKeyDNS yes") > > https://bugzilla.redhat.com/show_bug.cgi?id=180277 > https://bugzilla.redhat.com/show_bug.cgi?id=730558 > > You can't tell us to use this while at the same time refusing to make > that security setting not the system default > > I asked for this back in 2006 > > See the bug entry for my elaborate example showing you that DNS without DNSSEC > does NOT lead to automatically connecting to servers you were never on before > without prompting. Except nobody says or said that DNS without DNSSEC leads to the automatic connection with such setting. The objection (upstream one that is) is that setting VerifyHostKeyDNS yes ultimately sets you to depend on the DNSSEC security for your SSH connection security and that is something we will never make default if upstream does not. Setting it to 'VerifyHostKeyDNS ask' by default is another matter and I am OK with that. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 14:59 -0500, Mike McGrath wrote: > On Wed, 12 Oct 2011, Henrik Nordström wrote: > > > ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath: > > > > > Lots of people use and share keys across different projects. > > > > There is no security issue in sharing kes across different projects, > > other than that it gives a strong hint that you are the same person in > > both projects, much stronger than name or email. > > > > Sorry I didn't explain it very well. > > 1) People share keys across different projects. > 2) We've found PRIVATE keys on our servers > 3) We have no reason to believe private keys that can authenticate to > Fedora weren't on some of the compromised systems we've heard so much > about. > > You have to remember, lots of our contributors aren't highly technical. > Some don't even know what a private key is. They just follow the docs on > the website and get access to contribute. Not everyone is a packager. OK, but then you should not penalize also the people who keep their SSH private keys only on safe private computers. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 15:22 -0500, Mike McGrath wrote: > On Wed, 12 Oct 2011, Tomas Mraz wrote: > > > On Wed, 2011-10-12 at 14:59 -0500, Mike McGrath wrote: > > > On Wed, 12 Oct 2011, Henrik Nordström wrote: > > > > > > > ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath: > > > > > > > > > Lots of people use and share keys across different projects. > > > > > > > > There is no security issue in sharing kes across different projects, > > > > other than that it gives a strong hint that you are the same person in > > > > both projects, much stronger than name or email. > > > > > > > > > > Sorry I didn't explain it very well. > > > > > > 1) People share keys across different projects. > > > 2) We've found PRIVATE keys on our servers > > > 3) We have no reason to believe private keys that can authenticate to > > > Fedora weren't on some of the compromised systems we've heard so much > > > about. > > > > > > You have to remember, lots of our contributors aren't highly technical. > > > Some don't even know what a private key is. They just follow the docs on > > > the website and get access to contribute. Not everyone is a packager. > > > > OK, but then you should not penalize also the people who keep their SSH > > private keys only on safe private computers. > > > > First, asking people to change their key is work, not punishment. Unnecessary work is kind of punishment. BTW what prevents the people who do not care about their SSH private key security to upload their new SSH key to a compromised system immediately after their generate it again? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 22:50 +0200, Pierre-Yves Chibon wrote: > On Wed, 2011-10-12 at 16:27 -0400, Simo Sorce wrote: > > On Wed, 2011-10-12 at 12:55 -0700, Adam Williamson wrote: > > > On Wed, 2011-10-12 at 21:45 +0200, Tomas Mraz wrote: > > > > > > > That's a nonsense. Simply said. If I have a properly generated random > > > > ssh private key with a strong passphrase that I never put outside of my > > > > workstations and safe backup media then there is no other way it can be > > > > compromised than to compromise my workstation. > > > > > > Sadly, not everyone uses properly strong passphrases on their private > > > keys. Some people don't use passphrases at all, and short ones can be > > > brute forced. > > > > > > Workstations can be compromised in such a way as to compromise only a > > > subset of private keys, too. > > > > > > So, let's say I use the key ADAM to access my personal systems, and the > > > key FEDORA to access Fedora systems. > > > > > > When you first ssh into a remote system when you're using GNOME, GNOME > > > will prompt you for the key's passphrase, and there's a little drop down > > > labelled 'Details' which gives you some choices about when to re-lock > > > the key. By default it keeps the key open until you log out from GNOME, > > > but _you can change this_. > > > > > > Let's say I leave that setting on default for key ADAM, but change it to > > > 'lock after 1 minute' for key FEDORA. > > > > > > Now I go out and leave my laptop lying on the coffee shop table for two > > > minutes while I buy a coffee. Some dastardly person swipes said laptop. > > > > > > They high tail it off to their secure location, and quickly disable the > > > screen lock. Now they have access to my running session, and they can > > > ssh into my personal systems with impunity, because key ADAM is unlocked > > > until they log out. It's more than one minute since I last used key > > > FEDORA, though, so if they try and ssh into fedorapeople.org they'll > > > find that key is locked, and they can't screw around with Fedora. > > > > > > (Okay, so in practice, because of the FAS email loophole, they can just > > > reset my FAS password, log in, and change the ssh key. But the point > > > stands in theory: you can have stricter policies for some ssh keys than > > > others, and hence some can be compromised without all being > > > compromised.) > > > > Sorry Adam but this is BS, if your laptop is stolen you MUST replace all > > your keys anyways because you cannot count on them not being > > compromised, period. So this complex scenario is just mirrors and smoke. > > The point is, if you use one key they can access everything, if you use > several you actually have time to change your key before they are able > to brute-force the pass-phrase (assuming you use one). If they have my private SSH key they probably also have my passphrase and do not need to brute-force anything. Not saying that I do not use quite strong passphrase on my SSH private key but if someone is able to steal my private key he has the access to my machine and with that access he is probably also able to install a keylogger there. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 17:41 -0400, Sam Varshavchik wrote: > Kevin Fenzi writes: > > > New Password Rules: > > > > * Nine or more characters with lower and upper case letters, digits and > > punctuation marks. > > * Ten or more characters with lower and upper case letters and digits. > > * Twelve or more characters with lower case letters and digits > > * Twenty or more characters with all lower case letters. > > * No maximum length. > > Pop quiz, folks: > > Guess how many people will have their password set to > "abcdefghijklmnopqrstuvwxyz". > > It meets the new criteria. This is much easier to type and also passes: 12qwertyuiop :) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 18:17 -0400, Paul Wouters wrote: > On Wed, 12 Oct 2011, Tomas Mraz wrote: > > > Except nobody says or said that DNS without DNSSEC leads to the > > automatic connection with such setting. > > I answered that multiple times, including today with a vast amount of screen > pasting > into https://bugzilla.redhat.com/show_bug.cgi?id=180277 to show you that > DNS without DNSSEC does NOT lead to automatic connection in ANY case other > then > you already having the key in known_hosts, which is the same behaviour as > without > any SSHFP record in DNS. You seem to not understand that NEVER said that DNS without DNSSEC leads to automatic connection with the setting. That is not and never was the problem. You're just repeating things I know and knew at that time very well. > > The objection (upstream one that > > is) is that setting VerifyHostKeyDNS yes ultimately sets you to depend > > on the DNSSEC security for your SSH connection security > > It does not add any new dependancies. If there is no DNSSEC, you are told the > SSHFP > is in the DNS, shown the fingerprint like there is no SSHFP record, and asked > if > you really want to continue. If there is DNSSEC, no entries to known_hosts > are added > so whenever DNSSEC is not there, you fall back to exactly what you have now. > > Also, ssh already "depends" on DNSSEC to get a trustworth A/ record with > an RRSIG > from DNSSEC. The dependancy is there whether upstream likes it or not. Nope, you do not understand what the dependency is. Of course you depend on the DNS to not be compromised to get the IP address of the host but you still can verify the fingerprint on the first connection if you got it by other means. And in case you already have it in known_hosts it will explicitly disallow connection if the DNS gives you false answer and you'll connect to a different host. With 'VerifyHostKeyDNS yes' if there is a malicious DNS administrator, you will not have a chance to verify the fingerprint, you will be directly connected to a false server immediately compromising your password if password auth is used. And if this malicious DNS administrator controls the caching nameserver you're using for DNS queries, he can present you ANY data even 'valid' fake DNSSEC data. > > and that is > > something we will never make default if upstream does not. > > If upstream deems this so bad, why does upstream offer the option? I don't > see them > offering 1des or rot13 cipher either. Apparently, upstream is somewhat > divided? > > > Setting it to 'VerifyHostKeyDNS ask' by default is another matter and I > > am OK with that. > > Thank you, it's good enough for me and a happy end of a 5 year old bug. Feature request that is. And a change that is not to be taken lightly. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Thu, 2011-10-13 at 00:04 +0200, Henrik Nordström wrote: > ons 2011-10-12 klockan 21:41 +0200 skrev Thomas Spura: > > > I set them often to 1, but don't want to upkarma my own update because > > it feels like cheating... > > > > Especially updates, that fix a broken package, are an examples, that the > > current path (with forcing updates in updates-testing) taken is wrong > > and needs adjustment or more willing testers. > > If you know the current package is broken then direct pushing by using > your own testing & karma is no chating. > > Adding karma without testing is cheating, but if you already know that > the current package is seriously broken and that the same update in > other Fedora versions works fine then "cheating" is better than nothing. Unfortunately it is disallowed (not technically blocked though) under the current update rules to give your own update a +1 karma. I at least partially tried to change this rule but I did not get enough votes from other FESCo members for this change. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 2011-10-13 at 10:29 +0200, Benny Amorsen wrote: > Tomas Mraz writes: > > > And if this malicious DNS administrator controls the caching > > nameserver you're using for DNS queries, he can present you ANY data > > even 'valid' fake DNSSEC data. > > This is not generally true. Resolver libraries can (and should, IMHO) > verify DNSSEC themselves. Otherwise DNSSEC is somewhat pointless, > because it is precisely when you are stuck behind an untrusted Wifi > gateway that you need DNSSEC the most. Yes, they can and should. But they don't. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 2011-10-13 at 10:59 +0200, Ralf Corsepius wrote: > On 10/12/2011 09:59 PM, Mike McGrath wrote: > > On Wed, 12 Oct 2011, Henrik Nordström wrote: > > > >> ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath: > >> > >>> Lots of people use and share keys across different projects. > >> > >> There is no security issue in sharing kes across different projects, > >> other than that it gives a strong hint that you are the same person in > >> both projects, much stronger than name or email. > >> > > > > Sorry I didn't explain it very well. > > > > 1) People share keys across different projects. > > 2) We've found PRIVATE keys on our servers > > 3) We have no reason to believe private keys that can authenticate to > > Fedora weren't on some of the compromised systems we've heard so much > > about. > > 4) There are indications for keys being shared between indivuals. Which you dreamed up and made false accusations of. But let's suppose that anyone really shares their private keys on purpose what would prevent them to share them again if they change them? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo meeting agenda for 2011 Oct 24
Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #667 Request to fix CRITPATH update process .fesco 667 #topic #663 Late F16 Feature Java7 .fesco 663 = New business = No new tickets since last FESCo meeting. = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo meeting minutes for 2011-10-24
=== #fedora-meeting: FESCO (2011-10-24) === Meeting started by t8m at 17:00:16 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-10-24/fesco.2011-10-24-17.00.log.html . Meeting summary --- * init process (t8m, 17:00:34) * #667 Request to fix CRITPATH update process (t8m, 17:03:26) * Once again deferred based on pending bodhi change https://fedorahosted.org/bodhi/ticket/642 and statistics gathering. (t8m, 17:09:13) * #663 Late F16 Feature Java7 (t8m, 17:09:25) * LINK: https://fedorahosted.org/rel-eng/ticket/4932 (nirik, 17:11:42) * ACTION: t8m will remove this item from future meetings but will leave it open for the final update by dbhole (t8m, 17:16:08) * Fedora Engineering Services tickets (t8m, 17:16:44) * https://fedorahosted.org/fedora-engineering-services/report/6 (t8m, 17:16:54) * nothing much new here. Please see nirik if you would like to help out with FES (t8m, 17:17:30) * Next week's chair (t8m, 17:17:46) * sgallagh will chair 2011-10-31 meeting (t8m, 17:20:16) * Open Floor (t8m, 17:20:40) * Discussion about https://fedoraproject.org/wiki/Features/UsrMove (t8m, 17:26:45) * LINK: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken (cwickert, 17:28:12) * ACTION: rbergeron will start processing the F17 features for the next week meeting (t8m, 17:32:37) Meeting ended at 17:35:37 UTC. Action Items * t8m will remove this item from future meetings but will leave it open for the final update by dbhole * rbergeron will start processing the F17 features for the next week meeting Action Items, by person --- * rbergeron * rbergeron will start processing the F17 features for the next week meeting * t8m * t8m will remove this item from future meetings but will leave it open for the final update by dbhole * **UNASSIGNED** * (none) People Present (lines said) --- * t8m (47) * nirik (27) * haraldh (15) * cwickert (8) * zodbot (6) * rbergeron (5) * notting (5) * mbuf (3) * pjones (3) * mjg59 (0) * sgallagh (0) * mmaslano (0) * ajax (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 17:00:16 #startmeeting FESCO (2011-10-24) 17:00:16 Meeting started Mon Oct 24 17:00:16 2011 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:23 #meetingname fesco 17:00:23 The meeting name has been set to 'fesco' 17:00:28 #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 17:00:28 Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:00:34 #topic init process 17:00:37 * notting is here 17:00:41 * nirik is here. 17:00:41 hello all 17:00:47 * cwickert is here 17:00:51 oh hey it's that time. 17:01:15 I took the chair for Marcela who cannot attend today. 17:02:25 Anybody else from FESCo around? 17:02:46 But we have the quorum so I think we can start. 17:03:26 #topic #667 Request to fix CRITPATH update process 17:03:33 .fesco 667 17:03:37 t8m: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667 17:04:20 not sure I have anything new to report. 17:04:29 It seems the ticket is still unresolved. 17:04:30 proventesters have continued to meet... made a bit of progress. 17:04:57 I'm making a page for package tester resources: https://fedoraproject.org/wiki/Package_tester_resources help wanted. 17:05:20 I suppose the releng/admin resources now go to the F16 release? 17:05:27 also, we've talked about changing the join-fedora setup to not lump testers in with packagers/os developers... might get some more folks involved. 17:05:54 nirik, yep, that could help a little 17:05:54 I've not heard status on the bodhi ticket to allow a 2 week timeout. I can check on it tho. 17:06:10 nirik, I don't see any update there 17:07:06 mjg59, around? Any news about the critpath karma and proventester karma statistics? 17:07:34 I suppose we will have to defer this again to the next meeting. 17:07:39 he's in prague at kernel summit, dunno if he's planning on being here. 17:07:44 yeah, I think so 17:08:10 is this the Fedora Spins meeting? 17:08:15 no. 17:08:19 okay 17:08:20 mbuf, no, FESCo meeting 17:08:45 mbuf: spins is in 3 hours approx 17:08:48 Anybody proposes anything else for this ticket than defer? 17:08:56 no, defer 17:09:06 nirik: thanks 17:09:13 #info Once again deferred based on pending bodhi change https://fedorahosted.org/bodhi/ticket/642 and statistics gathering. 17:09:25 #topic #663 Late F16 Feature Java7 17:09:31 mbuf: spins meeting is at 20:00 UTC, 3 hours from now, in #fedora-meeting-1 17:09:31 .fesco 663 17:09:33 t8m: #663 (Late F16 Feat
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, 2011-10-25 at 09:06 +0200, Ralf Corsepius wrote: > On 10/25/2011 09:02 AM, Harald Hoyer wrote: > > On 10/24/2011 08:05 PM, Chris Adams wrote: > >>> === > >>> #fedora-meeting: FESCO (2011-10-24) > >>> === > >>> * Discussion about https://fedoraproject.org/wiki/Features/UsrMove > >>> (t8m, 17:26:45) > >> > >> This sounds interesting (speaking as an admin that typically sets up > >> servers with separate, ro-mounted, /usr). I'm not sure about moving > >> _everything_ to /usr, but I guess that's one approach. Other Unix > >> systems I've used have had /bin as a symlink to /usr/bin, but not /sbin > >> (still kept core system maintenance tools in /sbin on root fs). I'm > >> also not sold on eliminating sbin directories (I like having "system > >> admin" type stuff kept separate), and I don't see why that needs to be > >> rolled into the same feature (especially as just a footnote, not a > >> top-line change). > > > > What does it gain to have /sbin and /usr/sbin? > Not molest ordinary users with tools they are not supposed to used. +1 > > Security through > > obscurity? > Right, yes. Not by any means. Except if we made the whole /usr/sbin unreadable to regular non-root user. I do not think anyone sensible says that split of sbin and bin is done due to security. However this is not a problem. The split is useful for giving regular users only such tools into their $PATH that make sense to be used by regular users and not to confuse them with tools that they do not and cannot have any use of. > > > We already have it in $PATH for the normal user. > Right, Fedora made the mistake to do so. Exactly. This was not a good move at all. If there were any commands in sbin that are usable also for regular users then they should have been moved to bin. Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo Meeting Minutes for 2011-10-31
On Wed, 2011-11-02 at 09:31 +0530, Rahul Sundaram wrote: > On 11/02/2011 07:54 AM, Kevin Kofler wrote: > > Stephen Gallagher wrote: > >> * #683 - Zif as default PackageKit backend for desktop users - > >> http://fedoraproject.org/wiki/Features/ZifByDefaultForDesktop > >> (sgallagh, 17:03:32) > >> * AGREED: ZifByDefaultForDesktop is refused as a Feature for Fedora 17 > >> (sgallagh, 17:07:32) > > > > IMHO refusing this was a bad idea when the more general rule was originally > > decided and is still a bad idea now. You're essentially blackmailing zif > > upstream: "Either you fully support command-line users or you will never be > > the default in Fedora's PackageKit." > > I don't think this is the argument. Having potentially different > behaviour between command line dep resolver and gui dep resolver is very > problematic and this is a important concern. Exactly, Kevin is skewing the reason of the decision here. The reject is not based on the whole backend as is but purely on the depsolver algorithm. As soon as yum and zif share the depsolver (not just the transaction depsolver in rpm, but the depsolver solving which packages to put into the transaction), then zif would be allowed as the default backend for PackageKit. There were some proposals/ideas by the rpm developers to implement this depsolver in librpm although I do not know whether there was any progress in this recently. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: gnome-shell for everyone!
On Fri, 2011-11-04 at 10:17 -0800, Jef Spaleta wrote: > On Fri, Nov 4, 2011 at 9:35 AM, Matthew Garrett wrote: > > Shipping bug-free software is the job of maintainers. It's reasonable to > > ask a reporter to take an issue upstream if you feel that that'll result > > in the bug being fixed faster, but there's no reason to mandate that and > > it certainly doesn't match the common use of bugzilla. > > My personal policy. > > 1) If I can reproduce it, and I agree that its a bug, I'll try to > drive it forward and tell the reporter to poke me in the eye on some > reminder timescale..because you know..life happens..and reminders are > good. > > 2) if either of those two pre-conditions aren't satisfied, I encourage > them to file it upstream and hand be back a reference so I can track > it and respond if there's additional information needed that the > impacted user doesn't know how to provide. But at the end of the day, > I feel its most important to have upstream talking directly with the > person who can reproduce the problem. If I can't, I'm just a lossy > communication medium. That's exactly the same policy I apply as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote: > Hey, all. The topic of whether and which security issues should block > releases has come up several times before. While we haven't actually had > many really serious security issues to worry about since the > introduction of the current release criteria system, I think it's > certainly something we should take into account. At the same time, it's > fairly established in practice that we don't just consider anything > worth issuing a CVE for as a release-blocking bug. So, to capture what I > believe would be the intent of the project, I propose this as an Alpha > release criterion for F16 onwards. (For those on devel and security > lists who may not be completely familiar with the release criteria / > blocker system, this would mean that any bug for an issue which breached > the criterion should be considered a release blocker for any Alpha, Beta > or Final release). > > # There must be no known remote code execution vulnerability which could > be exploited during installation or during use of a live image shipped > with the release I mostly agree with this criterion with one exception below. > Points to consider: > > * Possible variants to the type of vulnerability covered...do we also > want to make local privesc vulns blocking? Conversely, do we want to > make only remote *root* execution vulns blocking? I don't know if anyone > would want to go as far as making DoS vulns release blocking, but speak > up if you would! (Of course there is again the local/remote distinction > to consider there: 'all DoS vulns' would be a much tighter standard than > 'remote DoS vulns'). > > * The caveat about where the issue is exploitable is important because > if you can't exploit it from the installer or a live image, it becomes > less relevant whether we ship with it or not, because you would be safe > with the first post-install update assuming we submitted an update for > the issue promptly. But it may be the case that we want to broaden it > out to also cover issues that can be exploited from a default DVD > install, if we consider the window between install and first update (if > updates repos aren't used during installation) to be unacceptable. I would vote for this slight broadening - that is to make also remotely exploitable issue in the default DVD install a release blocker. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 14:02 -0400, Adam Jackson wrote: > On 5/18/11 1:44 PM, Adam Williamson wrote: > > On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote: > >> On 5/18/11 1:22 PM, Kevin Kofler wrote: > >>> Adam Williamson wrote: > >>>> # There must be no known remote code execution vulnerability which could > >>>> be exploited during installation or during use of a live image shipped > >>>> with the release > >>> > >>> This is just completely and utterly moot considering that there are going > >>> to > >>> be many more unknown vulnerabilities than known ones, and that several of > >>> those are inevitably going to come up during the 6-month lifetime of a > >>> release. > >> > >> The difference between a known and an unknown security bug is that, if > >> _you_ know about it, it's virtually certain that someone malicious > >> already does too. > >> > >> We can't avoid unknown risk exposure. You're arguing for ignoring known > >> risk exposure entirely. Seems a touch irresponsible. > >> > >> Also: twelve month. > > > > Well, I think his point is that it's almost certain that some 'unknown' > > exposures will become 'known' during the life cycle of a release, at > > which point the live images we release three months previously are > > vulnerable to a known security exploit and there's exactly nothing we > > can do about it - so worrying about the ones we _can_ fix at release > > time becomes less important, when viewed from that perspective. It's a > > good point. > > It's a rationally argued position, but argued from an initial state that > does not reflect reality. > > I mean, the conclusion from that line of reasoning is that all releases > are futile: any sufficiently severe bug unknown at release time could be > discovered later, and could be so crippling as to make the release useless. > > I don't necessarily disagree with that logic either. However, we've > decided to do releases. Therefore we ought to have some standard of > quality for release content definition. After that it's all a matter of > drawing the line. I'd argue that knowingly exposing the user to a > remote root exploit is actively negligent behaviour; remote user code > execution, less so but still very bad; local privilege escalation, less > so still. > > I'd rather not ship something that I _know_ will result in the user > getting rooted. This is so fundamental a tenet of quality that I have > difficulty even believing someone could disagree. I guess Kevin's brain > is simply something I should stop being surprised by. Also note that targeting the heaps of poor users that are eager to try the newly shipped Fedora release would be probably much more easy and efficient than targeting one user installing the Fedora here or there a few months later. So yes, definitely remote root and user exploits in the installer, Live CDs, and in my opinion also the default install should be release blockers. By the way do we have statistics about when this kind of blockers happened during our previous releases? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what key between Ctrl & Alt (was: GNOME3 and au revoir...)
On Fri, 2011-06-17 at 09:05 -0400, Felix Miata wrote: > On 2011/06/17 08:53 (GMT-0300) Domingo Becker composed: > > > The shortest way is by using keyboard, as Rahul says: > > > 1. Press the key between Ctrl and Alt. > > What key between Ctrl & Alt? The last good[1] keyboards made (AFAIK) predate > keyboards with windows keys, so none of the keyboards I use routinely have > them. > > [1]good requires: > 1-function keys grouped on left so that only fingers of one child's (small) > hand are required to use any combination of function key simultaneously with > any combination of shift key(s); readily usable purely by touch of an > experience user > 2-standard inverted-T cursor keys with blank above up key and two blanks > above left and right keys > 3-oversize Enter key > 4-double width backspace key. The conditions 2, 3, 4 are still fairly commonly met although it seems to be harder to get such keyboard recently - at least here. However I thought that the condition 1 was abandoned when the original IBM AT keyboards stopped shipping :). But then a short search revealed this one: Avant Stellar Keyboard http://benchmarkreviews.com/index.php?option=com_content&task=view&id=376&Itemid=65&limit=1&limitstart=4 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
On Mon, 2011-06-20 at 10:34 -0700, Toshio Kuratomi wrote: > Due to the requirement for contributors to sign the FPCA by Thursday of last > week, certain package owners who haven't yet signed will be removed from the > packager group soon. When that happens, the packages that they own will be > orphaned. > > To try and minimize the problems this could cause, I'm publishing the > current list of packages to be orphaned and will start reassigning owners if > someone asks to take them over. We want to make sure that important > packages are not going to be orphaned by this change. We're planning on > removing people from packager and orphaning packages on Thursday if all goes > well. > > The list of packages being orphaned are listed below and the list of > packages with first level dependencies will be attached. Note that the > dependency list could be incomplete in two ways: > > 1) Since I'm using source package names, we don't capture things that dep on > a subpackage. > 2) The list does not follow the dep chain out to see if something relies on > something that relies on something that relies on a package that's being > orphaned. > > Please reply to this thread if you'd like to take any packages or ping me on > IRC and I'll reply to this thread with what packages have been taken. > (Needed since we aren't orphaning in the pkgdb until Thursday so you need > a cvsadmin to reassign ownership for now). > > > http://toshio.fedorapeople.org/fpca/packages_losing_owners.txt: I'll take the following two: > ctapi-common > pyOpenSSL -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Wed, 2011-06-22 at 21:55 -0400, Eric Paris wrote: > On 06/22/2011 03:02 PM, Matthew Garrett wrote: > > http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed > > feature for F16. We've traditionally had a hard objection to the > > functionality because it required either the distribution or downloading > > of binary code that ran on the host CPU, but it seems that there'll > > shortly be systems that incorporate the appropriate sinit blob in their > > BIOS, which is a boundary we've traditionally been fine with. > > Such systems supposedly exist today. I haven't tested them, but I > believe a number of the newer Dell systems already have the required > northbridge code in flash. tboot will use the binary northbridge setup > blob that may be passed to it or it will try to use any blobs built into > the flash if it isn't given a blob by grub. In the case that it doesn't > have the magic blob needed to set up the CPU and northbridge it just > won't execute the magic SENTER instruction. magic! > > > However, this is the kind of feature that has a pretty significant > > impact on the distribution as a whole. > > I actually think this is completely wrong. It shouldn't have ANY distro > wide impact at all. > > > Fesco decided that we should > > probably have a broader discussion about the topic. The most obvious > > issues are finding a sensible way to incorporate this into Anaconda, but > > it's also then necessary to make sure that bootloader configuration is > > updated appropriately. > > Agreed. These are exactly the parts that they need to do development. > Anaconda shouldn't really need changes, tboot is just a package that > needs installed. I'm not sure why that's even a part of the feature > request. If anaconda creates the initial grub.conf it might need some > work but that is the same issue as the next question. Grubby is what > needs discussion and new code. It will need to detect tboot is > installed and handle new grub type entries correctly. I haven't seen > any code for this, but handling new formats of grub entries is what is > really needed here. > > > Outside that, is there any other impact? > > There shouldn't be. Mind you if you want this to be useful for > something it's going to take more steps and layers on top, but just > booting into a measured launch environment should require no other steps. So to recap this for the next FESCo meeting(s). 1. There exists hardware that does not require any binary blobs to be downloaded or distributed within Fedora. 2. The feature does not have any substantial negative impact on the rest of the distribution (apart from requiring some integration work from grubby and anaconda maintainers). 3. What's really missing is the agreement between tboot, anaconda, and grubby maintainers on how to integrate the trusted boot into grubby and anaconda. Is that correct? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15: ugly behavior of "df"
On Thu, 2011-06-23 at 16:21 +0100, Pádraig Brady wrote: > On 23/06/11 15:53, Karel Zak wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=709351 > > > > The tools (not only df(1)) have to be fixed to de-duplicate the list > > of fileststems. It's standard behavior that the same filesystem could > > be mounted on more places. > > > > The 'bind' flag is another way how to achieve that the filesystem is > > mounted on another place. Nothing other. > > > ># mount /dev/sdb1 /mnt/A > ># mount --bind /mnt/A /mnt/B > > > > is the same thing as: > > > ># mount /dev/sdb1 /mnt/A > ># mount /dev/sdb1 /mnt/B > > > > there is nothing like 'bind' state of the filesystem. The 'bind' info in > > mtab was always broken by design. > > > > http://karelzak.blogspot.com/2011/04/bind-mounts-mtab-and-read-only.html > > Thanks for that info. > > I did a find_bind_mount() function as part of: > http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86 > I also adjusted df to handle bind mounts better with: > http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=0380e4c9 > I'll have to revisit these to see if they're still valid. > > I'll have a look at fixing up df (I guess I'll reverse the mount list > and have some internal hash to detect dupes?). > > I need to see why F15 has started doing this too. > For example on my system there are 2 _identical_ entries > for /home in /proc/mounts. If you have the sandbox package installed, that is the reason. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Fri, 2011-06-24 at 11:10 +0200, Miloslav Trmač wrote: > On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell wrote: > > If trusted boot in fedora is widely deployed, then $random_things may > > demand I use a particular fedora kernel in order to access them. > > I can't see how it would make any difference whether Fedora supports > the feature or not - after all, any vendor can add patch Fedora to add > TPM support and then "$random_things may demand you use a particular > vendor-modified Fedora in order to access them" - or a particular > non-Fedora operating system, just as well. Yes, I completely agree. What Gregory tries to emphasis here - as I understand it, of course he might have a different intention - is purely politics and I do not think, that Fedora should involve in political decisions in one way or another. If the feature conforms to Fedora legal requirements and the developers of the affected packages are OK with integrating necessary patches, it should be allowed. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On Fri, 2011-06-24 at 09:43 -0400, Gregory Maxwell wrote: > 2011/6/24 Tomas Mraz : > > On Fri, 2011-06-24 at 11:10 +0200, Miloslav Trmač wrote: > >> On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell > >> wrote: > >> > If trusted boot in fedora is widely deployed, then $random_things may > >> > demand I use a particular fedora kernel in order to access them. > >> > >> I can't see how it would make any difference whether Fedora supports > >> the feature or not - after all, any vendor can add patch Fedora to add > >> TPM support and then "$random_things may demand you use a particular > >> vendor-modified Fedora in order to access them" - or a particular > >> non-Fedora operating system, just as well. > > The userbase of Fedora as a whole is substantially larger than the > userbase of fedora users who run non-default kernels. The small > benefit of mandatory remote attestation could be far more easily > outweighed by the loss of the whole Fedora userbase than it could be > outweighed by the loss of the tiny subset of the Fedora users who are > actively practicing the freedom's theoretically provided by Fedora > (and wouldn't simply stop if the freedom was made costly by a > restriction). > > [I can make clear examples of cases where large relevant internet > resources chose to exclude userbases larger than > Fedora-users-with-modified kernels for just slight convenience, but > took inconvenience to support ones comparable in size to Fedora, but > I'm trying to stay scrupulously on-topic] > > > Yes, I completely agree. What Gregory tries to emphasis here - as I > > understand it, of course he might have a different intention - is purely > > politics and I do not think, that Fedora should involve in political > > decisions in one way or another. > > > > If the feature conforms to Fedora legal requirements and the developers > > of the affected packages are OK with integrating necessary patches, it > > should be allowed. > > I'm puzzled by this response. Would you also support Fedora packaging > and distributing proprietary binary only applications offered under a > license which legally allows Fedora to do so, but which disallowed the > end user the freedom to modify and understand the software? How is > this also not equally political? Oops I might not be clear enough in my response. With the "Fedora legal requirements" I meant not only the restrictions what can Fedora ship as allowed by laws of countries where Fedora is shipping but also the basic restriction that Fedora imposed upon itself within its roots and that is to provide only fully open source non-proprietary software (let's not dive into the firmware blobs issues now, please). And if trusted boot does not break this core requirement I think it should be allowed within Fedora. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2011-6-27)
On Mon, 2011-06-27 at 12:24 -0400, Bill Nottingham wrote: > Stephen Gallagher (sgall...@redhat.com) said: > > Following is the list of topics that will be discussed in the FESCo > > > > meeting tomorrow at 17:30UTC (1:30pm EDT) in #fedora-meeting on > > irc.freenode.net. > > I thought the decision at last meeting was 1700 UTC/1pm EDT? +1 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning gnet2
I orphaned the gnet2 package as workrave does not depend on it anymore. Feel free to take it - especially if your package depends on it. Even better would be to drop it as upstream is dead and GIO should be used instead. However these packages still depend on it in Rawhide: gcompris-0:9.5-4.fc15.x86_64 gnome-mud-0:0.11.2-7.fc15.x86_64 gurlchecker-0:0.10.1-14.fc16.x86_64 odccm-0:0.11.1-4.fc15.x86_64 synce-hal-0:0.15-2.fc15.x86_64 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Tue, 2010-02-02 at 21:54 +0100, Till Maas wrote: > On Tue, Feb 02, 2010 at 09:30:44PM +0100, Tomas Mraz wrote: > > On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote: > > > On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote: > > > > > > > I am sorry, but I do not see a real need for special guideline for the > > > > fipscheck checksums. The policy where these checksums should/will be > > > > placed should be decided by the fipscheck package itself. Of course I > > > > > > As soon as multiple packages are affected, there should be a guideline > > > to document how something needs to be done to work, e.g. if someone > > > wants to package a new software that contains fips checksums. > > > > Huh, shouldn't reading documentation in fipscheck package be > > sufficient? > > Afaik, it would be the first packaging documentation that's in a package > instead of the wiki. It would probably not be indexed by search engines > and not as easy reachable by people building packages for Fedora, who do > not run Fedora themselves. But maybe these reasons are not that applicable > for fipscheck, because there is only a limited set of packages that make > use of it. Isn't it logical to have it documented in the fipscheck? If you want to use fipscheck you have to know where it looks for the checksums. And yes, I do not think there will be more packages with the .hmac checksums than they are currently in the near future. Of course "never say never" but anyway they will not be widespread because of the costs associated with FIPS module certification which means that it is highly improbable that the number of such modules with support for the certification will raise substantially. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Tue, 2010-02-02 at 22:56 +0100, Björn Persson wrote:
> Tomas Mraz wrote:
> > The library will work fine and it will not compute the checksum at all
> > if the FIPS mode is not enabled which is the normal situation.
>
> Then perhaps FIPS mode can be left disabled until /usr has been mounted, so
> that the checksum can be in %{_libdir}/fipscheck?
I am not sure this is possible. In following, albeit quite theoretical,
scenario libgcrypt would be needed to mount encrypted filesystem holding
the /usr tree. Such operation would be probably required to be running
with the libgcrypt already in the FIPS mode.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Mon, 2010-03-08 at 21:59 +, Matthew Garrett wrote: > This is the policy that I expect to be discussed during the Fesco > meeting tomorrow. This is entirely orthogonal to the ongoing discussions > regarding whether updates in stable releases should be expected to > provide features or purely bugfixes, and I don't see any conflict in > introducing it before those discussions have concluded. > > Introduction > > > We assume the following axioms: > > 1) Updates to stable that result in any reduction of functionality to > the user are unacceptable. > > 2) It is impossible to ensure that functionality will not be reduced > without sufficient testing. > > 3) Sufficient testing of software inherently requires manual > intervention by more than one individual. > > Proposal > > > The ability for maintainers to flag an update directly into the updates > repository will be disabled. Before being added to updates, the package > must receive a net karma of +3 in Bodhi. I am strongly against this proposal if it is enforced on all the packages as a whole. It might be acceptable for critical path packages however low profile packages which are not installed on most of the systems (and we have huge number of such packages now in Fedora) will not get the testing no matter what magic you will cast on the users to attract them to testing. A reasonable compromise might be to allow the manual push to stable after a week or so of the package living in the testing repository. Somehow speeding up the process of getting the package to the hands of users once it is entered into bodhi would be also appreciable. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
On Thu, 2010-03-11 at 11:53 +0100, Alexander Kahl wrote: > Most of what is described here is already covered by Nix (leaving out > the hardware driver part). > > This is why I endorse dumping yum, RPM *and* the stupid FHS in favor of > Nix, focusing all development on something that is clearly superior by > substantiating the synthesis of DOS (*cough*) and POSIX style > installations: Minimal redundancy, maximum compatibility, (mostly) > predictable rollbacks, atomicity, referential transparency: Purely > functional package management. > > Oh, and by the way, we could leave behind all those discussions > regarding dynamic linking: RPATH for everything and everyone. If you've > linked against libfoo-4.2-2 during build time, libfoo-4.2-2 will be > present during runtime, same location, same file. Period. :) I'm sorry for not studying the Nix concepts in depth, but can you please answer me just a simple question how security or other critical bugfixes _in libraries_ are handled under this "RPATH for everything" paradigm? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: POSTUN scriptlet failure in rpm package cyrus-sasl
On Thu, 2010-03-11 at 10:04 -0500, Toshio Kuratomi wrote: > On Thu, Mar 11, 2010 at 02:31:43PM -, Quentin Armitage wrote: > > See https://bugzilla.redhat.com/show_bug.cgi?id=572399 > > > > > >> groupdel: group 'saslauth' does not exist Non-fatal POSTUN scriptlet > >> failure > >> in rpm package cyrus-sasl > >> warning: %postun(cyrus-sasl-2.1.23-4.fc12.i686) scriptlet failed, exit > >> status 6 > >> > >> > >> This looks benign, but I suppose it could check if the group exists before > >> attempting to delete it. > >> > > There's actually a not so benign side of this. Here's what the Guidelines > say about removing groups: > > """ > We never remove users or groups created by packages. There's no sane way to > check if files owned by those users/groups are left behind (and even if > there would, what would we do to them?), and leaving those behind with > ownerships pointing to now nonexistent users/groups may result in security > issues when a semantically unrelated user/group is created later and reuses > the UID/GID. Also, in some setups deleting the user/group might not be > possible or/nor desirable (eg. when using a shared remote user/group > database). Cleanup of unused users/groups is left to the system > administrators to take care of if they so desire. > """ > > https://fedoraproject.org/wiki/Packaging:UsersAndGroups > > I've updated bugzilla with this information as well. Someone should perhaps correct the http://fedoraproject.org/wiki/PackageUserCreation then. Or add some rules on how to resolve conflicts among the current rules. (I'm joking.) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Example of karma not being functional [Was:POSTUN scriptlet failure in rpm package cyrus-sasl]
On Fri, 2010-03-12 at 07:58 -0800, Jesse Keating wrote: > On Fri, 2010-03-12 at 09:58 +0100, Andreas Schwab wrote: > > If the user/group saslauth is not needed by cyrus-sasl, why has it > > been > > added in the first place? > > > > > > Packaging bug or some leftover, but it appears the user/group isn't used > for anything. So the package functions, but there are still some > packaging bugs. It is the user which can be used if the admin uncomments the appropriate line in /etc/sysconfig/saslauthd. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
NuFW license change to GPLv3
The NuFW changed its license to GPLv3 from GPLv2. This applies also to the libnuclient library as NuFW subpackage. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Moving libcrypto.so.* back to /lib
So I got convinced that libcrypto.so.* should be moved back to /lib in the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.* will stay in /usr/lib though. I will do that change in F14 packages. Till Maas asked me for this change also in F13, but I am a little hesitant to do this as I am afraid of regressions. Do you think this change could break things in F13? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit
On the today's FESCo meeting we discussed the request to move forward the conversion of the sysvinit scripts to systemd units in Fedora 17. The packages which ship sysvinit script but do not ship systemd unit according to the Fedora packaging guidelines violate this rule: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files Eventual blocking of the packages that violate this Fedora packaging rule was not yet definitively decided upon, but we agreed that the Fedora package maintainers should be warned that such blocking might happen before the Fedora 17 Alpha release. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit
On Mon, 2011-11-07 at 10:35 -0900, Jef Spaleta wrote: > On Mon, Nov 7, 2011 at 10:28 AM, Tomas Mraz wrote: > > Eventual blocking of the packages that violate this Fedora packaging > > rule was not yet definitively decided upon, but we agreed that the > > Fedora package maintainers should be warned that such blocking might > > happen before the Fedora 17 Alpha release. > > > Two questions, > > 1) Do we have an accurate list of the packages in this category. And > more importantly how many of these have closed CLAs in the packaging > trees which would prevent me as a good Samaritan from digging in and > committing a service file into the rawhide branch. The closed CLA > situations are going to be the touchiest, so lets not get blindsided > by those in the 11th hour. No, we do not have the list. Yet? Please add the question to the ticket: https://fedorahosted.org/fesco/ticket/687 > > 2) And it would be very good if there was a clearly stated mandate > from FESCO that gave proven-packagers expressed authority to deal with > this on a case by case basis once this becomes a ticking clock > situation. I think the proven-packagers had this mandate already during the F16 development and this mandate did not expire in any way. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit
On Tue, 2011-11-08 at 12:37 +, "Jóhann B. Guðmundsson" wrote: > On 11/08/2011 12:04 PM, Lennart Poettering wrote: > > Yupp, newer versions might want to use /run instead of /var/run, and > > drop all references to syslog.target. But then again, this is not key, > > as nothing breaks if they do. > > This is such a large scale change that it's better to make them future > proof from the get go instead of making it a feature and having to do > all that work in later release cycles ( one less cleanup to do in the > long run ). > > Arguable environment file reference pointing to /etc/sysconfig/$foo > should be dropped too since admins/power users should just copy the > relevant unit to /etc/systemd/system directory and make any changes to > the unit there as opposed to be doing that in /etc/sysconfig/$foo file > or daemons be (re)written to support config file(s). This is still very debatable as it means any update to the unit file in the package will not be reflected on the system anymore. So for simple things like adding commandline parameters or setting environment variables for services it is still very preferable to keep having separate /etc/sysconfig/$foo. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Libs with applications
On Sun, 2011-11-20 at 21:36 +, John5342 wrote: > On Sun, Nov 20, 2011 at 19:33, Steve Grubb wrote: > > On Sunday, November 20, 2011 02:14:09 PM drago01 wrote: > >> On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler > >> wrote: > >> > Steve Grubb wrote: > >> >> For example, if a 32 bit library is installed, which application is left > >> >> - the 64 or 32 bit one? > >> > > >> > If you install ONLY the 32-bit multilib, the 32-bit version. > >> > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version > >> > (on all the platforms where 64-bit is preferred, which includes x86_64 > >> > and now also ppc64). > >> > If you install ONLY the 64-bit package, the 64-bit version. > >> > >> Yeah which means there isn't really a problem here. > > > > Well, yeah there is the other problem of dependencies and getting a smaller > > minimal > > install. For example, libnotify. > > > > # ldd /usr/bin/notify-send | wc -l > > 44 > > # ldd /usr/lib64/libnotify.so.1.2.3 | wc -l > > 12 > > > > or how about libmsn > > # ldd /usr/bin/msntest | wc -l > > 20 > > # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l > > 9 > > I am the maintainer of libmsn. msntest probably could be moved to a > subpackage but it is a small program. All of the dependencies found by > ldd are already required by the applications using libmsn and msntest > is also very useful for checking if a problem connecting to msn is > caused by libmsn or the settings/applications using it. I would be > happy to move msntest into a subpackage if it is specifically > requested but under the current circumstances it would gain nothing > and just add an extra package to the repos. Exactly. In case the binaries shipped along with the library do not pull any additional dependencies and they are reasonably small, there is no need to put them into extra subpackages. At least not until rpm drops the multilib and file-coloring support. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Agenda for today's FESCo meeting (28th November, 2011)
Following is the list of topics that will be discussed in the FESCo meeting today at 18:00UTC (1:00pm EST) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #667 Request to fix CRITPATH update process .fesco 667 #topic #699 Proposal to remove the package "tzdata" from Critical Path .fesco 699 = New business = #topic #705 Reconsider when to shut off updates-testing by default .fesco 705 #topic #706 Are updates guidelines descriptive or prescriptive? .fesco 706 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from yesterday's FESCo meeting (2011-11-28 at 18UTC)
46 we are discussing this topic for 30 mins 19:17:07 mmaslano: In terms of not using US idioms and such? Can do. 19:17:14 officially: 19:17:24 * abadger1999 has enough to work on a new draft 19:17:28 #proposal have abadger1999 come up with clearer wording for the policy 19:17:28 abadger1999: that would be first great thing ;-) 19:17:46 notting, I don't think we have to vote on this 19:17:55 ... ok 19:18:38 #action abadger1999 will come up with clearer wording for the policy 19:19:26 There are three features that were added to the ticket system recently. Do we want to vote on them today? 19:19:57 i'm fine to go through them now. others? 19:20:03 i would have to abstain from two of them, since they're my features. 19:20:05 * sgallagh has to leave now 19:20:36 fine to go thru them for me. 19:20:40 do we still have quorum? 19:20:47 I think so 19:20:59 Still here 19:21:12 * mmaslano is also here, so please quickly 19:21:19 ok, let's go through them 19:21:38 #topic #708 F17 Feature: DRI2 Drivers only - http://fedoraproject.org/wiki/Features/DRI2DriversOnly 19:21:47 .fesco 708 19:21:48 t8m: #708 (F17 Feature: DRI2 Drivers only - http://fedoraproject.org/wiki/Features/DRI2DriversOnly) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/708 19:22:07 +1 here. 19:22:16 * ajax here to field questions 19:22:36 +1 19:22:37 +1 19:23:06 ajax: as i read this, this means 'dropping dri1 GL drivers', not 'drop all X drivers that do not have dri2 support' 19:23:08 ? 19:23:31 notting: correct. i couldn't possibly do the latter anyway (vesa etc) 19:23:41 i can clarify that on the feature page though 19:23:42 +1, then 19:23:50 +1 19:24:01 #agreed The feature is allowed 19:24:27 ajax, please put that statement on the feature page 19:24:52 #topic #709 F17 Feature: Software rendering for gnome-shell - https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering 19:24:58 .fesco 709 19:24:59 t8m: #709 (F17 Feature: Software rendering for gnome-shell - https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/709 19:25:04 +1 19:25:06 +1 19:25:23 +1 19:25:24 +1 19:25:28 +1 19:25:39 #agreed The feature is allowed 19:25:48 #topic #710 F17 Feature: Inscript2 Keymaps - https://fedoraproject.org/wiki/Features/Inscript2_Keymaps 19:25:54 .fesco 710 19:25:55 t8m: #710 (F17 Feature: Inscript2 Keymaps - https://fedoraproject.org/wiki/Features/Inscript2_Keymaps) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/710 19:26:23 +1 19:26:25 +1 19:26:32 +1 19:26:51 sure, +1 19:27:05 +1 19:27:08 +1. summary could be reworded a bit, but, whatever 19:27:18 #agreed The feature is allowed 19:27:48 I suppose we do not have anything new on the Engineering services tickets? 19:27:54 nope. 19:28:03 #topic Next week chair 19:28:04 please see me if you wish to help out reviving things there. 19:28:35 Anybody volunteers to be next week chair? 19:29:52 can't do next week .can do two weeks from now 19:30:22 * mmaslano is not sure wheter it's the first meeting of new fesco or not 19:30:40 Oh yeah 19:30:42 oh, yeah, 2011-12-05 is the end of elections. 19:30:43 People should go and vote 19:30:44 I could do it if i'm still member ;-) 19:31:07 yeah, it would be the current fesco again next week... 19:31:11 then the next folks the week after. 19:31:20 i could do one last time i suppose 19:31:52 ajax: it's yours ;-) 19:32:14 #action ajax is the next week chair as it will be his last time in FESCo :) 19:32:24 suitable punishment ;) 19:32:24 (for now) 19:32:44 #topic Open Floor 19:33:09 I have one announcement/reminder: 19:33:36 #info REMINDER: Please change your password and upload a new ssh key if you have not already. Deadline is 2011-11-30! 19:33:39 http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html 19:34:32 * nirik has nothing else. 19:35:37 I will end the meeting if nobody speaks up in a minute. 19:36:12 * shaiton will start in 2 minutes then ^^ 19:36:48 #endmeeting -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Change in the stable updates policy for critical path packages
The Fedora policy for push of the updates of critical path packages to the stable updates is now changed. The policy now allows to push the critical path package update to stable updates after the update spent 14 days in testing and there are no negative karma points on the update. Please refer to the https://fedoraproject.org/wiki/Updates_Policy wiki page for further details. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
On Mon, 2011-12-12 at 15:21 -0500, Stephen Gallagher wrote: > On Mon, 2011-12-12 at 13:16 -0700, Ken Dreyer wrote: > > On Mon, Dec 12, 2011 at 12:24 PM, Stephen Gallagher > > wrote: > > > * #715 Provenpackager education/status/brainstorming (sgallagh, > > > 18:43:02) > > > > There was some discussion a while back about preventing certain > > extensions from being uploaded to the lookaside cache. Could ".patch" > > be added to that list? > > > Not a terrible idea. ".diff" should also be a candidate if we go that > route. > > > Of course, a whitelist might be a better idea. Maybe we only > allow .tar.gz, .tar.bz2 and .zip to be uploaded this way and make > additional exceptions as they arise. What about running a 'file' command on the stuff and if the output contains 'text' then allow upload only with some kind of --force option? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
On Mon, 2011-12-12 at 22:52 +0200, Jussi Lehtola wrote: > On Mon, 12 Dec 2011 21:34:12 +0100 > Tomas Mraz wrote: > > On Mon, 2011-12-12 at 15:21 -0500, Stephen Gallagher wrote: > > > On Mon, 2011-12-12 at 13:16 -0700, Ken Dreyer wrote: > > > > On Mon, Dec 12, 2011 at 12:24 PM, Stephen Gallagher > > > > wrote: > > > > > * #715 Provenpackager education/status/brainstorming (sgallagh, > > > > > 18:43:02) > > > > > > > > There was some discussion a while back about preventing certain > > > > extensions from being uploaded to the lookaside cache. Could > > > > ".patch" be added to that list? > > > > > > Of course, a whitelist might be a better idea. Maybe we only > > > allow .tar.gz, .tar.bz2 and .zip to be uploaded this way and make > > > additional exceptions as they arise. > > > > What about running a 'file' command on the stuff and if the output > > contains 'text' then allow upload only with some kind of --force > > option? > > And what about separately shipped license files, documentation and so > on? > > Not a valid option. What's wrong with using --force option for such files? These are not that common so that should not be much hassle. Also if they are small I do not see any reason why not to put them directly into the git repository. Or maybe the condition for need of the force flag could be modified to not require it for files larger than some size (for example 100kBytes) even if 'file' outputs that they are a text files. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
On Mon, 2011-12-12 at 22:06 +0100, Tomas Mraz wrote: > On Mon, 2011-12-12 at 22:52 +0200, Jussi Lehtola wrote: > > On Mon, 12 Dec 2011 21:34:12 +0100 > > Tomas Mraz wrote: > > > On Mon, 2011-12-12 at 15:21 -0500, Stephen Gallagher wrote: > > > > On Mon, 2011-12-12 at 13:16 -0700, Ken Dreyer wrote: > > > > > On Mon, Dec 12, 2011 at 12:24 PM, Stephen Gallagher > > > > > wrote: > > > > > > * #715 Provenpackager education/status/brainstorming (sgallagh, > > > > > > 18:43:02) > > > > > > > > > > There was some discussion a while back about preventing certain > > > > > extensions from being uploaded to the lookaside cache. Could > > > > > ".patch" be added to that list? > > > > > > > > Of course, a whitelist might be a better idea. Maybe we only > > > > allow .tar.gz, .tar.bz2 and .zip to be uploaded this way and make > > > > additional exceptions as they arise. > > > > > > What about running a 'file' command on the stuff and if the output > > > contains 'text' then allow upload only with some kind of --force > > > option? > > > > And what about separately shipped license files, documentation and so > > on? > > > > Not a valid option. > > What's wrong with using --force option for such files? These are not > that common so that should not be much hassle. Also if they are small I > do not see any reason why not to put them directly into the git > repository. > > Or maybe the condition for need of the force flag could be modified to > not require it for files larger than some size (for example 100kBytes) > even if 'file' outputs that they are a text files. I created RFE bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=767264 with proof of concept patch. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, 2012-02-09 at 04:24 +, Matthew Garrett wrote: > On Thu, Feb 09, 2012 at 02:14:53AM +0100, Kevin Kofler wrote: > > > IMHO, FESCo needs to accept that sometimes they make a mistake (especially > > if the vote was disputed to begin with) and revote. UsrMove should have > > been > > unapproved, not only for F17, but forever. > > So, just to be clear, you're saying that even if usrmove had landed in > an entirely perfect and complete form the day after F16 branched, it > should still have been rejected? You're talking about completely theoretical situation nobody is arguing on. It is theoretical because there is still not _perfect and complete form_ of the UsrMove feature. Yes, most of the objections to it were eventually fixed/workarounded/rebutted but I'm sure not all of them. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, 2012-02-09 at 10:06 +0100, drago01 wrote: > On Thu, Feb 9, 2012 at 8:57 AM, Tomas Mraz wrote: > > On Thu, 2012-02-09 at 04:24 +, Matthew Garrett wrote: > >> On Thu, Feb 09, 2012 at 02:14:53AM +0100, Kevin Kofler wrote: > >> > >> > IMHO, FESCo needs to accept that sometimes they make a mistake > >> > (especially > >> > if the vote was disputed to begin with) and revote. UsrMove should have > >> > been > >> > unapproved, not only for F17, but forever. > >> > >> So, just to be clear, you're saying that even if usrmove had landed in > >> an entirely perfect and complete form the day after F16 branched, it > >> should still have been rejected? > > > > You're talking about completely theoretical situation nobody is arguing > > on. > > Well Keven wrote "UsrMove should have been unapproved, not only for > F17, but forever." ... so he just oppose the feature per se not its > state. Perhaps he thinks that "entirely perfect and complete form of UsrMove" is impossibility and that the cons will always overweight the pros in case of this feature. I certainly think it is impossibility to do an entirely perfect and complete form of UsrMove. I don't say that I wouldn't accept "almost perfect and complete form with better gains than presented currently" but talking about "entirely perfect and complete form of anything" is nonsense. And I do not want to speak for Kevin - he certainly could mean other things with his quoted phrase. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, 2012-02-10 at 12:29 +0100, Matthias Runge wrote: > On 10/02/12 12:11, Michael Schroeder wrote: > > (We're mostly doing it because to provide some kind of Fedora > > compatibility for 3rd parties.) > > What? You don't think, there are other/better reasons to do this? > Harald and Kay described better/other reasons on their feature-page. > > I think this is really astonishing! I hope that this is just sarcasm. Many of the reasons were refuted to not be real. Of course there are still some positive reasons remaining but they are very weak in comparison to the break of expectations of existing users and developers of 3rd party software. So if you mainly ignore the existing expectations you might come to a conclusion that this feature is a net gain however this is by no means certain thing and undisputable. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: > On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Dear developers, > > > > Now that the /usrmove changes have landed in the F-17 branch, should > > the ordering of directories in PATH be changed? /usr/bin should appear > > before /bin and /usr/sbin before /sbin. > > > > Right now $(which a-binary) would report that all /usr/... binaries > > are located in /bin and /sbin instead; while it is mostly just > > cosmetic, some programs (e.g. pure-gen) use the heuristic of computing > > their default installation prefix based on the location of another > > binary, and get confused if that prefix is empty. > > > > Is this a reasonable change? I'll file a bug report if that's the case. > > /bin and /sbin paths were already removed in latest setup package - as > you no longer need them... so no need for bugzilla and report... I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Thu, 2012-02-16 at 10:22 +0530, Rahul Sundaram wrote: > On 02/16/2012 10:08 AM, Genes MailLists wrote: > > > Not to mention that the kernel devs use gcc to compile the kernel - > > and it most certainly puts a lot of pressure on the compiler. I suspect > > unless linus drops gcc as well, we'll at a minimum need to keep it to > > build the kernel itself. > > Not quite. LLVM can be used to build the kernel and what Linus does > doesn't matter as much (kernel is important but only one component) as > showing that Fedora on the whole will actually benefit from moving to > LLVM. For that, LLVM has to so much better than GCC and someone has to > do the work within Fedora to show that it is the case. It's very unfortunate that this high standard of requirements for disruptive changes in Fedora wasn't properly applied to some of the recent disruptive changes. Particularly the very recent unnamed disruptive change in Fedora 17. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On Tue, 2012-03-06 at 11:27 -0500, Paul Wouters wrote: > On Tue, 6 Mar 2012, Daniel J Walsh wrote: > > >> Why /etc/default dir is used instead of /etc/sysconfig? To be > >> honest - it's not really user friendly from long time RH Linux user > >> POV. > >> > > Just disable SELinux in /etc/selinux/config. > > Or the more obvious place for people with /etc/sysconfig hardcoded in > their brain, /etc/sysconfig/selinux :) > > Though to be honest, F17 is the first version where I have been working > with selinux enabled for more then two days. In fact, I have left it > enabled since I installed F17 weeks ago. > > I think the only somewhat "valid" reason to disabled selinux is if people > are using special directories they made up, eg /vol or /opt or anything. > (or when copying/dealing with /var/lib/libvirtd/images content in other > locations :) Using /vol /opt and other special directories semanage fcontext is your best friend. It is easily manageable to have your own directories for content with SElinux. Problems start to appear when you need to share some content files between daemons/services that are not shareable with the stock SELinux policy as that means you need to start to add policy modules to allow the access. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for today's FESCo Meeting (2012-03-12) Note the time change in US!
Following is the list of topics that will be discussed in the FESCo meeting today at 18:00UTC (1:00pm EST, 2:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #699 Proposal to remove the package "tzdata" from Critical Path .fesco 699 #topic #800 Feature Freeze exception: JBoss AS 7 .fesco 800 = New business = #topic #820 Feature Freeze exception: Mingw-w64 cross-compiler .fesco 820 #topic #707 Updates to language on FESCo Election page .fesco 707 #topic #819 Please review our determination of IPv6 issue blocker status .fesco 819 #topic #808 Unretiring policy (or Fedora policies in general) needs a "common sense" clause .fesco 808 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary & minutes for today's FESCo meeting (2012-03-12)
=== #fedora-meeting: FESCO (2012-03-12) === Meeting started by t8m at 18:02:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-03-12/fesco.2012-03-12-18.02.log.html . Meeting summary --- * init process (t8m, 18:02:39) * #699 Proposal to remove the package "tzdata" from Critical Path (t8m, 18:05:03) * LINK: http://meetbot.fedoraproject.org/teams/fesco/fesco.2011-11-21-18.00.log.html#l-115 (nirik, 18:13:02) * Deferred to next meeting (t8m, 18:54:26) * #800 Feature Freeze exception: JBoss AS 7 (t8m, 18:54:29) * LINK: http://fedoraproject.org/wiki/JBossAS7 has the packaging status (nirik, 18:56:52) * AGREED: The feature freeze exception for JBoss AS 7 is granted. (t8m, 18:57:42) * #820 Feature Freeze exception: Mingw-w64 cross-compiler (t8m, 18:58:13) * AGREED: The feature freeze exception for Mingw-w64 cross-compiler is granted (t8m, 19:00:47) * #707 Updates to language on FESCo Election page (t8m, 19:01:45) * AGREED: The updates to the FESCo Election page as described in the ticket are approved. (t8m, 19:04:14) * ACTION: t8m will update the page (t8m, 19:05:45) * #819 Please review our determination of IPv6 issue blocker status (t8m, 19:06:03) * AGREED: FESCo agrees with the IPv6 issue blocker status. (t8m, 19:07:54) * #808 Unretiring policy (or Fedora policies in general) needs a "common sense" clause (t8m, 19:08:21) * AGREED: Packages may be unretired without review up to 2 weeks after retirement providing that the package has ever previously been reviewed (t8m, 19:19:00) * ACTION: t8m will update the orphaning page and announce it on devel (t8m, 19:20:40) * Next week chair (t8m, 19:24:08) * ACTION: limburgher will be the next week chair (t8m, 19:27:23) * Open floor (t8m, 19:28:24) Meeting ended at 19:31:23 UTC. Action Items * t8m will update the page * t8m will update the orphaning page and announce it on devel * limburgher will be the next week chair Action Items, by person --- * limburgher * limburgher will be the next week chair * t8m * t8m will update the page * t8m will update the orphaning page and announce it on devel * **UNASSIGNED** * (none) People Present (lines said) --- * t8m (101) * nirik (63) * mjg59 (55) * mitr (47) * notting (31) * pjones (29) * limburgher (29) * zodbot (10) * adamw (5) * dgilmore (1) * sgallagh (0) * mmaslano (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Adjustment to deprecated package policy approved by FESCo
On the FESCo meeting today the deprecated package policy was adjusted. We agreed on the following proposal: Packages may be unretired without review up to 2 weeks after retirement providing that the package has ever previously been reviewed. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, 2012-03-16 at 15:16 +, Matthew Garrett wrote: > On Fri, Mar 16, 2012 at 04:13:31PM +0200, Muayyad AlSadi wrote: > > > > > > As I understand it, Muayyad has different problem. Right now, the > > > /etc/sysctl.conf we ship is not empty. It has several values set, one of > > > them is sysrq=0 he used in his example. No one set this is value, it's > > > just > > > default value and yet, no package can change it by placing its file in > > > /etc/sysctl.d This would work only if sysctl.conf is empty and all default > > > configuration is moved to /etc/sysctl.d/00-systemdefault.conf > > > > yes exactly this is the case, > > we have sysrq=0 in /etc/sysctl.conf > > No package should be automatically changing the sysrq policy. No Fedora package should do that. However I can imagine situation when sysadmin wants his own package to do it. I have to second the request to be the default /etc/sysctl.conf empty and moving the Fedora defaults to sysctl.d/00-systemdefault.conf. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary & minutes for today's FESCo meeting (2012-03-19)
On Tue, 2012-03-20 at 09:12 -0600, Kevin Fenzi wrote: > Well, speaking for myself only, I read this as pretty much a "Lets > begin discussions on it". There's no way a short bit at the end of a > meeting is going to allow enough discussion. > > So, this is just to start the ball rolling and collect feedback from > everyone. No need to feel bad about not being there to give feedback at > this first meeting. +1, I do not see any harm in starting the discussion on the yesterday meeting as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: > This is very much a draft, but I'd like to start a discussion regarding > what we expect from primary architectures. Feedback not only welcome, > but actively desired. > In order to ensure that these expectations are met, secondary > architectures must meet various criteria before they can be promoted: ... > 4) All supported platforms must have kernels built from the Fedora > kernel SRPM and enabled by default in the spec file. Each kernel must be > built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Of course the general requirement that builds on the architecture to be promoted must not take much longer time than builds on the current primary architectures still stays. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: > On Wed, 24.11.10 15:22, Paul Wouters (p...@xelerance.com) wrote: > > > > > On Wed, 24 Nov 2010, Lennart Poettering wrote: > > > > > BTW, regarding at and cron: what I was thinking of but never check > > > ehwther it is feasible is to make cron/at autostart a soon as some job > > > is scheduled. I.e. use .path trigger to check whether /etc/crontab and > > > user jobs exist, and start cron only then. Similarly for at. That way we > > > could support cron and at just fine, and wouldn't even have to run it by > > > default. I haven't looked into this in detail however, to see if the > > > file triggers systemd offers in .path units are already sufficient to > > > make this work. > > > > What if no jobs are there and a non-root user adds a crontab later on? Who > > will start cron (as root) ? > > That's the point of the .path unit. i.e. you can list dirs to watch. If > a user then drop a file into one of those dirs cron gets automatically > started. > > Basically, in your .path unit you'd write something like this: > > [Path] > PathExists=/etc/crontab > DirectoryNotEmpty=/etc/cron.d > DirectoryNotEmpty=/var/spool/cron > > And the moment where /etc/crontab starts to exist, or somebody drops a > file into /etc/cron.d or /var/spool/cron crond would be automatically > started. But what is the point of this? The /etc/crontab always exists and there always are some files in /etc/cron.d. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: > 2010/11/25 Tomas Mraz : > > On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: > >> That's the point of the .path unit. i.e. you can list dirs to watch. If > >> a user then drop a file into one of those dirs cron gets automatically > >> started. > >> > >> Basically, in your .path unit you'd write something like this: > >> > >> [Path] > >> PathExists=/etc/crontab > >> DirectoryNotEmpty=/etc/cron.d > >> DirectoryNotEmpty=/var/spool/cron > >> > >> And the moment where /etc/crontab starts to exist, or somebody drops a > >> file into /etc/cron.d or /var/spool/cron crond would be automatically > >> started. > > > > But what is the point of this? The /etc/crontab always exists and there > > always are some files in /etc/cron.d. > > Actually it's true, but in the near future all standard cron jobs > might be runned by systemd > > http://0pointer.de/public/systemd-man/systemd.timer.html > > It's not 100 % cron replacement now, but who knows what the future holds :) I suppose the future holds systemd replacing the whole operating system. Resistance is futile. You will be assimilated. :) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: > 2010/11/25 Tomas Mraz : > > On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: > >> That's the point of the .path unit. i.e. you can list dirs to watch. If > >> a user then drop a file into one of those dirs cron gets automatically > >> started. > >> > >> Basically, in your .path unit you'd write something like this: > >> > >> [Path] > >> PathExists=/etc/crontab > >> DirectoryNotEmpty=/etc/cron.d > >> DirectoryNotEmpty=/var/spool/cron > >> > >> And the moment where /etc/crontab starts to exist, or somebody drops a > >> file into /etc/cron.d or /var/spool/cron crond would be automatically > >> started. > > > > But what is the point of this? The /etc/crontab always exists and there > > always are some files in /etc/cron.d. > > Actually it's true, but in the near future all standard cron jobs > might be runned by systemd > > http://0pointer.de/public/systemd-man/systemd.timer.html > > It's not 100 % cron replacement now, but who knows what the future holds :) To add some argument to my previous sarcasm. I do not think that it makes any sense to replicate cron functionality in systemd. Either you replicate half of it and then you still need to run crond for the rest or you replicate it completely. But in that case what is the saving over the separate daemon? I'm sorry but I do not think that crond is anything that "optimized out" by inclusion can improve performance of Linux desktop/server/whatever. I do not say that cronie code cannot be improved - it definitely can - but it does not make any sense to reimplement it from scratch. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Fri, 2010-11-26 at 02:07 +0100, Miloslav Trmač wrote: > Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100: > > On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote: > > And also, cron does a couple of really nasty things. For example it > > wakes up in regular intervals to check if a job is ready to run. It does > > so to deal with wallclock time changes/suspends. In systemd we are > > working on a different way to solve this, so that we can actually sleep > > as long as possible, and don't have to wake up in regular > > intervals. > Great. You can fix cron then, this does not mean it is necessary to > integrate the two. > > > To summarize this: the current logic of cron is not pretty. And it > > duplicates process spawning and babysitting which already exists in way > > too many daemons, > I think you'll find the execution of processes is a comparatively small > part of cron. And anyway, "process spawning and babysitting" will > _always_ exist in many different daemons, unless you want to run the > whole system within a single systemd process. It would be much much > better for the ecosystem to extract these parts of systemd into a > library (perhaps standalone, perhaps interacting with the system-wide > systemd runtime) that can be used in any other process that needs to run > a task in a separately tracked "daemon group". +1 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Fri, 2010-11-26 at 03:05 +0100, Lennart Poettering wrote: > On Fri, 26.11.10 02:07, Miloslav Trmač (m...@volny.cz) wrote: > > > Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100: > > > On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote: > > > And also, cron does a couple of really nasty things. For example it > > > wakes up in regular intervals to check if a job is ready to run. It does > > > so to deal with wallclock time changes/suspends. In systemd we are > > > working on a different way to solve this, so that we can actually sleep > > > as long as possible, and don't have to wake up in regular > > > intervals. > > Great. You can fix cron then, this does not mean it is necessary to > > integrate the two. > > Well, I actually believe we should design an OS here, not just a set of > independent tools. And that means I think closer integration is good and > only has benefits. I agree you are trying to design a completely new OS here. I am not so sure this OS will be better than any other fully integrated monolithic OS. I originally did not want to write this, but it seems you are really determined to break some of the basic and proven to be effective Unix design philosophy rules to make the system from simple parts with clearly defined interfaces and functionality. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
