GPG and SHA1
Hi, With the current trend in Debian to move out of DSA into RSA [1], and considering the theoretical (and probably correct) attack just presented [2], what are we planning to do? I am curious about the potential impacts -- compatibility, cost (both CPU-wise and conversion-wise), and proposed Ubuntu standard. Notice that this might as well involve a change to the gpg defaults, key generation utilities (seahorse, and equivalents), etc. In other words, it can have a high impact both for our internal usage (maintainer keys) as for the end-users. I am not advocating either way: 2^52 is still a large value (and, as such, still costly to attack); but it is safe to state that the time to move out of SHA1 is coming sooner than later, and we might get it done right if we start thinking about it now. Thanks, [1] http://www.debian-administration.org/users/dkg/weblog/48 [2] http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Need advice on versioning scheme for project in Ubuntu
On Fri, May 8, 2009 at 3:42 PM, Francesco Fumanti wrote: > Hello, > > > Could anybody please give me any advice about how to handle the > versioning of a project hosted on launchpad with the aim to match the > Ubuntu release schedule? > > The help pages of launchpad suggest to keep the front of developing in > trunk. On the other hand, I suppose that it is advisable to have a > series for each Ubuntu release (hardy, jaunty, karmic,...) for potential > bug fixes after the ubuntu release has gone final. [snip] > Could anybody please tell me or point me to instructions about how this > problem is usually approached? There's many ways to go about it. The suggestion on LP is just that, a suggestion. Feel free to use what ever system works best for you. That said, a common way to work is to do development in trunk. Once you are getting ready to release, you can branch the release series from trunk. Then you make no more major changes or additional features on that branch. You can release stable point releases from that branch, cherry-picking only bug fixes from trunk. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Need advice on versioning scheme for project in Ubuntu
Hello, Could anybody please give me any advice about how to handle the versioning of a project hosted on launchpad with the aim to match the Ubuntu release schedule? The help pages of launchpad suggest to keep the front of developing in trunk. On the other hand, I suppose that it is advisable to have a series for each Ubuntu release (hardy, jaunty, karmic,...) for potential bug fixes after the ubuntu release has gone final. Let's suppose that 0.92 is the version of the project that should correspond to the karmic cycle. My problem: If the development takes place in trunk, how can I publish tarballs from the 0.92 series during the development cycle of karmic? (I think that it is odd to develop in trunk and publish the releases in the 0.92 series.) Could anybody please tell me or point me to instructions about how this problem is usually approached? Thanks in advance for any help. Francesco -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: High CPU usage applet
Hi, do you know the hardware-monitor applet? I've extended this applet to have exactly this feature. It shows in the tooltip processes which consume lot's of cpu or memory ressources. But because I'm not a gnome/gtk programmer I couldn't get "kill" buttons into the tooltip. If you are interested I can post the patched version of this applet. But this applet still has one problem: It fails to run/compile on Jaunty because of depencies to old libs. But if you use Intrepid you will have no problems. Cheers, Martin Am Freitag, den 08.05.2009, 13:47 +0100 schrieb Andrew Sayers: > I think this is a really good idea. Making it an applet would let you > list "suspects" (programs that have a high CPU load, or use a lot of > memory, etc.), then send a STOP signal to processes guilty beyond a > reasonable doubt, before asking the user what to do. > > I once played around with a command-line program that looked for > applications that were page-faulting like it was going out of style, by > repeatedly reading /proc/[0-9]*/stat. If you're interested in pursuing > this idea yourself, I'd be happy to send along the (C++) code I wrote > back then. > > - Andrew > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: group access to local devices on shared networked machines
On Fri, 2009-05-08 at 11:36 -0500, Patrick Goetz wrote: > Scott James Remnant wrote: > > Provided they are on the same physical console as the local optical > > drive, this is done automatically. > > > > Well, we need to retain the option of people ssh'ing to the machine and > using the optical drive remotely; however even for users logged in on > the console, this most definitely was NOT working in Hardy -- we found > out the hard way when users starting showing up complaining that they > were getting "permission denied" when trying to access the optical > drive. Note that our users are network users authenticated using LDAP, > not local users. > It should not matter how your users are authenticated, provided that you are using an LDAP Name Service Switch - they will appear equivalent to local users. This should have worked in Hardy: With one of the users logged in, could you run "ck-list-sessions" ? Likewise, with a user logged in via ssh, could you run "ck-list-sessions" ? Users logged in by gdm will be registered in ConsoleKit as local users (is-local = TRUE); users logged in by ssh will be registered in ConsoleKit as non-local users. > Is this a change for Jaunty? If so, this basically my question: how is > it being done? If there is now a canonical way (pun intended) for > network users to get permission to use local devices, then we can drop > our /etc/security/groups.conf work around. > System -> Administration -> Authorisations Scroll down to the /org/freedesktop/hal/device-access/Directly access optical drives authorisation, and select it. In the right-hand pane, you can adjust the parameters - and for example, grant additional explicit authorisations Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: group access to local devices on shared networked machines
Scott James Remnant wrote: >> > Provided they are on the same physical console as the local optical > drive, this is done automatically. > Well, we need to retain the option of people ssh'ing to the machine and using the optical drive remotely; however even for users logged in on the console, this most definitely was NOT working in Hardy -- we found out the hard way when users starting showing up complaining that they were getting "permission denied" when trying to access the optical drive. Note that our users are network users authenticated using LDAP, not local users. Is this a change for Jaunty? If so, this basically my question: how is it being done? If there is now a canonical way (pun intended) for network users to get permission to use local devices, then we can drop our /etc/security/groups.conf work around. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: group access to local devices on shared networked machines
On Fri, 2009-05-08 at 10:28 -0500, Patrick Goetz wrote: > Would anyone care to elaborate on this, as we brought this up with > Canonical support well over a year ago for Hardy and no good solution > was offered at that time (so we came up with our own). > > The problem: how to provide access to, say, local optical drives to > incidental ldap users who aren't automatically in the device groups > since they're not local users. > > Our solution was to use pam. By adding these lines to the > /etc/security/group.conf file: > >*;:0|tty*&!ttyp*;*;Al-2400;dialout,dip,audio,video >*;*;*;Al-2400;cdrom,floppy,scanner,plugdev,storage,vboxusers,fuse > > console users are added, for example, to the audio/video groups while > anyone who logs in from anywhere is added to the cdrom/scanner groups > (this allows users to use the scanners and optical devices remotely). > > I'm most curious to know if there is now a better way of providing this > functionality to network users. > Provided they are on the same physical console as the local optical drive, this is done automatically. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
group access to local devices on shared networked machines
> Date: Tue, 05 May 2009 11:17:04 +0100 > From: Scott James Remnant > Subject: Re: Usev permissions and USB scanners > On Sun, 2009-05-03 at 16:16 +0300, kohe...@gmail.com wrote: > > I created a usbdev group and added my user to that group, added a > > group setting to that line instead of the recommended mode change, > > and my scanner works, > We prefer not to use groups in this way. > Instead we use ACLs on devices such as scanners so that logged in > console users can directly access the device without needing to be in > any special group. > Further access can be granted through the "Authorizations" tool. Hi - Would anyone care to elaborate on this, as we brought this up with Canonical support well over a year ago for Hardy and no good solution was offered at that time (so we came up with our own). The problem: how to provide access to, say, local optical drives to incidental ldap users who aren't automatically in the device groups since they're not local users. Our solution was to use pam. By adding these lines to the /etc/security/group.conf file: *;:0|tty*&!ttyp*;*;Al-2400;dialout,dip,audio,video *;*;*;Al-2400;cdrom,floppy,scanner,plugdev,storage,vboxusers,fuse console users are added, for example, to the audio/video groups while anyone who logs in from anywhere is added to the cdrom/scanner groups (this allows users to use the scanners and optical devices remotely). I'm most curious to know if there is now a better way of providing this functionality to network users. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The creeping religion of click on this
> From: Jeff Hanson > Subject: Re: The creeping religion of click on this > To: ubuntu-devel-discuss@lists.ubuntu.com > Mandriva's GUI tool interface has a log option that shows > what is actually being done. That would work. Perhaps such a log feature should be a required standard for Ubuntu/gnome GUI interface administration tools? It certainly would help with debugging. This is linux. There simply is no excuse for trying to hide the details from people who desperately crave them. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: High CPU usage applet (how to use apport to report CPU hogs)
Timo Sirainen wrote: > If some process has been eating 100% CPU for hours, there should be some > kind of a notification that it's happening. Like a small icon could > appear to gnome panel and clicking it would show the process details and > allow to kill it. > > Nowadays with multicore processors this 100% CPU usage can be difficult > to notice. I've had it happen several times and lasting for over a week > until I finally realized the system is running slower than normal. > > (I know about the existing system monitor applet. I don't want a > distracting animation on my screen.) > > Great idea, here is another proposed solution that utilizes apport as well. I have been in this position as well, I have quad core machine with 8gb RAM and I had just re-installed it so I did not have the CPU meter added as a GNOME applet yet. I had this machine in this state for almost a week before I finally added the CPU metering applet and saw it. Once 8-core becomes the norm I don't even think the "CPU status graph tools" we have today will be enough because I'm very much used to xorg and what not taking up like 1-5% of my CPU all the time when I'm working on stuff so if one core out of eight is maxed out that means the graphing tool showing like 10% all over CPU load which is a bit of a distortion of the real situation I'd say. Problems get's even worse with 16 cores etc. I think an appropriate solution would be to force each app to tag itself with a "LICENSED_TO_HOG_THE_CPU" badge before it starts to hog the CPU with 100% intensity for extended periods of time. Once we have a way for apps to tell us "yes i'm hogging the CPU by design" we can just fire up an apport dialog asking the user if he wants to report the CPU hogging as a bug to LP. If some apps gets incorrectly reported we'll just fix that by making sure that they activate the "LICENSED_TO_HOG_THE_CPU" badge/tag before they hog CPU and that they remove the marker/tag when they stop their CPU intensive run. Clearly some processes like "s...@home" or whatever should be allowed to always be marked with the LICENSED_TO_HOG_THE_CPU tag but normal apps should only mark themselves with the tag for short periods of time while they know that they will (or might) hog the CPU for a valid reason. For example, if apt needs to rebuild some package database or whatever, then that process should mark itself with the tag, do the necessary computations and then unmark itself. Of course the apport thing won't trigger until a process runs with 100% CPU for like 60 full seconds without having the LICENSED_TO_HOG_THE_CPU marker, and because of this most apps will never need any changes at all. And if too many changes in too many apps are needed, one option would be to invert the meaning of the marker so that certain processes gets marked with a tag that means THIS_PROCESS_MAY_NOT_USE_100_CPU_FOR_LONGER_THAN_10_SECS or similar. I'd love to have such a tag on pulseaudio for example which runs into CPU spins every now and then and never for valid reasons. I actually think a system like this could undercover a range of interesting bugs and performance problems. Martin -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: High CPU usage applet
I think this is a really good idea. Making it an applet would let you list "suspects" (programs that have a high CPU load, or use a lot of memory, etc.), then send a STOP signal to processes guilty beyond a reasonable doubt, before asking the user what to do. I once played around with a command-line program that looked for applications that were page-faulting like it was going out of style, by repeatedly reading /proc/[0-9]*/stat. If you're interested in pursuing this idea yourself, I'd be happy to send along the (C++) code I wrote back then. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
