[arch-general] kernel 2.6.33.3 freezes on boot
Hi list, Since todays's update of the kernel (2.6.33.2 - 2.6.33.3) my Dell inspiron 1012-9118 (new mini 10) netbook freezes on boot (after displaying loading modules. I have to poweroff. It is an Atom N450 proc and an x86_64 Archlinux (up-to-date). Has anyone a similar problem?
Re: [arch-general] kernel 2.6.33.3 freezes on boot
Am 28.04.2010 09:43, schrieb didier gaumet: Hi list, Since todays's update of the kernel (2.6.33.2 - 2.6.33.3) my Dell inspiron 1012-9118 (new mini 10) netbook freezes on boot (after displaying loading modules. I have to poweroff. It is an Atom N450 proc and an x86_64 Archlinux (up-to-date). Has anyone a similar problem? Likely the update breaks some external modules. Do you have any module packages installed that are not part of the kernel package? If yes, you can append disablemodules=module1,module2 to the kernel commandline. These modules may have to be rebuilt - if you find some, tell us which ones they are. If you have no idea, appending verbose to the commandline may give more clues. signature.asc Description: OpenPGP digital signature
Re: [arch-general] kernel 2.6.33.3 freezes on boot
On Wed, 2010-04-28 at 09:43 +0200, didier gaumet wrote: Hi list, Since todays's update of the kernel (2.6.33.2 - 2.6.33.3) my Dell inspiron 1012-9118 (new mini 10) netbook freezes on boot (after displaying loading modules. I have to poweroff. It is an Atom N450 proc and an x86_64 Archlinux (up-to-date). Has anyone a similar problem? Happened on first boot after upgrade here. but it hasn't happened since. I rebooted 5 times to check
Re: [arch-general] kernel 2.6.33.3 freezes on boot
Le 28/04/2010 09:54, Thomas Bächler a écrit : Likely the update breaks some external modules. Do you have any module packages installed that are not part of the kernel package? If yes, you can append disablemodules=module1,module2 to the kernel commandline. These modules may have to be rebuilt - if you find some, tell us which ones they are. I have not built any module myself, all my modules are provided either by kernel26 package or core packages. If you have no idea, appending verbose to the commandline may give more clues. I have done that, please refer to my answer to Nilesh. Thanks.
Re: [arch-general] kernel 2.6.33.3 freezes on boot
Am 28.04.2010 11:10, schrieb didier gaumet: Le 28/04/2010 09:54, Thomas Bächler a écrit : Likely the update breaks some external modules. Do you have any module packages installed that are not part of the kernel package? If yes, you can append disablemodules=module1,module2 to the kernel commandline. These modules may have to be rebuilt - if you find some, tell us which ones they are. I have not built any module myself, all my modules are provided either by kernel26 package or core packages. Which core packages have you installed that contain modules? signature.asc Description: OpenPGP digital signature
Re: [arch-general] dual ISP: 1)cable broadband (DHCP) 2){shudder} dial-up (ppp?) Please help!
Joe(theWordy)Philbrook (2010-04-28 02:21): ... I searched the wiki for wvdial and all I got was instruction for configuring non-root access (which is the last thing I want. When/if connected via dialup, I'll be paying by the connected hour, so I don't want anyone I don't trust with the root password to be able to use it... Offtopic: This anyone I don't trust with the root password sounds strange to me. There should be only one root... I'm hoping that All I'll need to do is open a terminal window, su to a root shell, type wvdial Then open a browser or email client in another window. And to be able to quickly pull the plug on the connection (stopping the ISP's connect time clock) by switching back to the root shell that started wvdial and hitting ^C... (that is of course after a root shell runs wvdialconf and then edits the wvdial.conf to include the appropriate DNS server, user and password data etc...) Do I need to worry about wvdial and/or other dial-up ppp connection messing with the broadband Ethernet setup? ISPs usualy charge per minute, so there is no need to be in a hurry pulling the plug. Are you really getting nervous when thinking about dial-up, or am I imagining things? wvdial will not touch any of your network related configs (only the ppp ones), so if you will not use any other tools, your broadband will be safe. At least after reboot. wvdialconf has to be run only once. It should ask you for the telephone number, user and password. Later, to connect, you simply run wvdial and wait for the connection (it will fetch the DNS settings, set the default gateway etc.). Then pressing ^C, it will disconnect and change the settings back to what they were. But, if you do not test dialing-up at home, it is likely that something will go wrong when you try connecting at your sister's (and there won't be any internet connection to seek help). And are you sure the modem in your laptop is working and recognized by linux? Could someone point me at the URLs of the other 'dialup' related documents that are supposed to be in the Arch Linux Wiki (since searching for 'dialup' didn't help me)? Did you search for ppp? -- -- Rogutės Sparnuotos
Re: [arch-general] dual ISP: 1)cable broadband (DHCP) 2){shudder} dial-up (ppp?) Please help!
Do I need to worry about wvdial and/or other dial-up ppp connection messing with the broadband Ethernet setup? That should not be a problem. Could someone point me at the URLs of the other 'dialup' related documents that are supposed to be in the Arch Linux Wiki (since searching for 'dialup' didn't help me)? Well, I haven't succeeded in doing this, and it is the only thing keeping me from ditching OSX on my macbook, but it should be possible to use netcfg for this. So it should just be a matter of disconnecting your ethernet-profile and connecting to your dialup-profile. The forums have a few solutions, but neither has worked for me. Mind you: I am trying to connect to my BT smartphone, and use that as a dialup-modem. Your setup should be easier. Zl.
Re: [arch-general] dual ISP: 1)cable broadband (DHCP) 2){shudder} dial-up (ppp?) Please help!
It would appear that on Apr 28, Rogutės Sparnuotos did say: Joe(theWordy)Philbrook (2010-04-28 02:21): ... When/if connected via dialup, I'll be paying by the connected hour, so I don't want anyone I don't trust with the root password to be able to use it... Offtopic: This anyone I don't trust with the root password sounds strange to me. There should be only one root... Not so off topic... ;-7 I did specifically bring up the concept of trusting someone with root access (and I wasn't referring to a limited sudoer) But be that as it may, while I can imagine a few circumstances involving more than one admin with root privileges, in practice I've only got my personal Linux box. And since my life partner isn't very computer literate, that means I'm the only one I trust with my root password, so I don't want anybody but me jacking up my back-up isp bill... I'm hoping that All I'll need to do is open a terminal window, su to a root shell, type wvdial Then open a browser or email client in another window. And to be able to quickly pull the plug on the connection ... Actualy I'm thinking I should maybe get in the habit of doing that via $ su -c wvdial Do I need to worry about wvdial and/or other dial-up ppp connection messing with the broadband Ethernet setup? ISPs usualy charge per minute, so there is no need to be in a hurry pulling the plug. Are you really getting nervous when thinking about dial-up, or am I imagining things? Not at all. It's been so long since I bothered that I've forgotten almost everything I ever knew about Linux dialup except about how much cooperation I'll get from the ISP's tech dept. right after a let the word Linux slip past my lips... So yeah, when you add to that a shoe string budget, I'm willing to admit I'm just a tad nervous. wvdial will not touch any of your network related configs (only the ppp ones), so if you will not use any other tools, your broadband will be safe. At least after reboot. Good. Then I can afford 'some' empirical testing after all. ;-) From what I've found online, and what little I can remember, wvdial should be available for just about any distro. So if I keep it's set up fairly simple, I should be able to clone a successful implementation to the other Linux installed on my multi-boot laptop. So yeah, as long as you don't count set-up utilities such as wvdialconf, and if need be, minicom, I don't plan on using any other dialup tools... wvdialconf has to be run only once. It should ask you for the telephone number, user and password. That's good to know. From what I read in the man page I was under the impression that it would only configure the modem part of the wvdial.conf and that I'd have to manually edit in the login data... Later, to connect, you simply run wvdial and wait for the connection (it will fetch the DNS settings, set the default gateway etc.). Then pressing ^C, it will disconnect and change the settings back to what they were. So then, I won't need to specify the DNS, AND it will restore any such existing settings. (I knew that wvdial was the one for me...) But, if you do not test dialing-up at home, it is likely that something will go wrong when you try connecting at your sister's (and there won't be any internet connection to seek help). Absolutely. That was my plan. Else I wouldn't have worried about some brain flatulence causing me to accidentally have the Ethernet cable connected, while wvdial was active. And are you sure the modem in your laptop is working and recognized by linux? Not yet! :-( But if I can't get it working I've got my old external serial modem in one of the assorted junk boxes that clutter up my office. What I won't find though, is the manual for it sigh (I'd much prefer to be able to use the built in... (fewer things to lug around and all that) Could someone point me at the URLs of the other 'dialup' related documents that are supposed to be in the Arch Linux Wiki (since searching for 'dialup' didn't help me)? Did you search for ppp? Doh! And to think I didn't think of that. I knew I suffered from CRS... But now I'm thinking it must be getting worse... Actually though, I've never been particularly skillful at coming up with good search strings. But I still should have thought of that one. Thanks! -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
[arch-general] Package signing
Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Short description follows. Use case for developers: 1. Dev bulds package with f.e. -sign switch. 2. Dev enters passphrase. 3. makepkg builds the package and creates detached signature (now we have 2 files *.tar.xz and *.sig). 4. The two files togeather are distributed to the repos as package with signature. Package installation: Pacman additionally downloads the signature the signature file and verifies the package. Problems: 1. Where to store the package signature file? It is more convenient and logical to keep the package as a single file. Rpm packages uses binary format and the signatures are stored inside. 2. GPG key sharing. Rpm-like distros like fedora and RHL use a single key for signing all their stable packages, but I think their build system is centralised. Is it safe to share one key among all package developers? 3.. Implementation: 1. Add package verification suport in lipalpm (using gpgme or gpg executable as rpm does). 2. Add package signing in makepkg script 3. Patch pacman, add option to turn the package signing ON or Off. 4. Add support for signed package distribution if needed (see Problems #1) 5. Include Arch public pgp key in /etc/pacman.d/..(??) Discussion about this and also other ways for package signing(md5,..) are welcome! -- Alekss
Re: [arch-general] Crisp Rendering Fonts
On 28/04/2010 14:13, Carlos Mennens wrote: Is there any suggestion on Arch Linux running Gnome 2.6.30 to improve the crisp / clearness of my fonts? I installed the latest available nVidia drivers under 'Appearance' 'Fonts' 'Details', I show the following: * Resolution: 98 dots per square inch. * Smoothing: Subpixel (LCD) * Hinting: Slight * Subpixel Order; RGB It just never seems as clear and crisp when I compare side by side to Ubuntu or Windows 7. The font clarity is notable difference beween Arch and I would like to change this. Any help and or tips would be greatly appreciated! -Carlos Install the -cleartype, -lcd or -ubuntu patches for Cairo from the AUR. Ananda
Re: [arch-general] Package signing
On 28/04/10 23:32, Aleksis Jauntēvs wrote: Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Good to see someone interested in this. I suggest you join the pacman-dev list where all discussion about pacman development occurs. There is also some code floating around that has started to implement this. This is my gpg branch containing those patches - http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg . Allan
Re: [arch-general] Package signing
On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote: On 28/04/10 23:32, Aleksis Jauntēvs wrote: Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Good to see someone interested in this. Yes, the monthly forum threads were a bit tiring. I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?).
Re: [arch-general] Package signing
On 28/04/10 23:52, Ng Oon-Ee wrote: On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote: On 28/04/10 23:32, Aleksis Jauntēvs wrote: Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Good to see someone interested in this. Yes, the monthly forum threads were a bit tiring. I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?). The need for testers usually occurs after implementation! :)
Re: [arch-general] Package signing
On Wed, 2010-04-28 at 23:56 +1000, Allan McRae wrote: On 28/04/10 23:52, Ng Oon-Ee wrote: On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote: On 28/04/10 23:32, Aleksis Jauntēvs wrote: Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Good to see someone interested in this. Yes, the monthly forum threads were a bit tiring. I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?). The need for testers usually occurs after implementation! :) Well, it does seem like a multi-part project, so I'm sure even before a total implementation there would be bits and pieces to test (functionality in pacman, for example, that nobody would use because the rest of the supporting cast isn't there yet).
[arch-general] Nvidia Driver Installed But Not Running
I recently installed the nvidia driver from 'Pacman' and rebooted. I have not since updated / upgraded the kernel. I notice that when I try and open my 'nVidia X Server Config' window and it tells me: You do not appear to be using the NVIDIA X driver. Please edit your X configuration file. I looked in /etc/X11/ directory and don't see xorg.conf file. Does anyone know how I can get my nVidia drivers working on Arch Linux? It installed fine however it's not running for some reason. -Carlos
Re: [arch-general] Nvidia Driver Installed But Not Running
On 29/04/10 00:45, Carlos Mennens wrote: I recently installed the nvidia driver from 'Pacman' and rebooted. I have not since updated / upgraded the kernel. I notice that when I try and open my 'nVidia X Server Config' window and it tells me: You do not appear to be using the NVIDIA X driver. Please edit your X configuration file. I looked in /etc/X11/ directory and don't see xorg.conf file. Does anyone know how I can get my nVidia drivers working on Arch Linux? It installed fine however it's not running for some reason. Have a look at the NVIDIA page in the wiki. It gives detailed information on setting this up (hint: nvidia-xconfig)
Re: [arch-general] Nvidia Driver Installed But Not Running
On 04/28/10 20:15, Carlos Mennens wrote: I recently installed the nvidia driver from 'Pacman' and rebooted. I have not since updated / upgraded the kernel. I notice that when I try and open my 'nVidia X Server Config' window and it tells me: You do not appear to be using the NVIDIA X driver. Please edit your X configuration file. I looked in /etc/X11/ directory and don't see xorg.conf file. Does anyone know how I can get my nVidia drivers working on Arch Linux? It installed fine however it's not running for some reason. -Carlos You need to configure it, create your Xorg configuration file by logging in as root in runlevel 3 and typing this command: Xorg -configure It will create xorg.conf.new or whatever. Copy it to /etc/X11/xorg.conf -- Nilesh Govindarajan Site Server Administrator www.itech7.com मेरा भारत महान ! मम भारत: महत्तम भवतु !
Re: [arch-general] Nvidia Driver Installed But Not Running
Am 28.04.2010 16:48, schrieb Allan McRae: On 29/04/10 00:45, Carlos Mennens wrote: I recently installed the nvidia driver from 'Pacman' and rebooted. I have not since updated / upgraded the kernel. I notice that when I try and open my 'nVidia X Server Config' window and it tells me: You do not appear to be using the NVIDIA X driver. Please edit your X configuration file. I looked in /etc/X11/ directory and don't see xorg.conf file. Does anyone know how I can get my nVidia drivers working on Arch Linux? It installed fine however it's not running for some reason. Have a look at the NVIDIA page in the wiki. It gives detailed information on setting this up (hint: nvidia-xconfig) I particularly like that it suffices to use the following minimal xorg.conf file, the rest is automatically generated: http://wiki.archlinux.org/index.php/Nvidia#Minimal_configuration Without it, Xorg will NOT try to use the nvidia driver and fall back to nv, nouveau or vesa. signature.asc Description: OpenPGP digital signature
[arch-general] Remove Epiphany Browser
I just installed a fresh system today with Gnome 2.6.30. It automatically installed Epiphany Epiphany Web Bookmarks too. I would like to know if I remove both of these applications, will I effect Gnome or any of it's dependancies? I wont ever use Epiphany and I don't like useless applications lingering on my system? Is there a way to purge all of it's installation existance off my new machine without messing up Gnome?
Re: [arch-general] Nvidia Driver Installed But Not Running
Thanks all! It's working on my system looks amazing!
Re: [arch-general] kernel 2.6.33.3 freezes on boot
On 28.04.2010 09:43, didier gaumet wrote: Hi list, Since todays's update of the kernel (2.6.33.2 - 2.6.33.3) my Dell inspiron 1012-9118 (new mini 10) netbook freezes on boot (after displaying loading modules. I have to poweroff. It is an Atom N450 proc and an x86_64 Archlinux (up-to-date). Has anyone a similar problem? Does it continue after hitting the 180s timeout? -- Sven-Hendrik
Re: [arch-general] Remove Epiphany Browser
On 04/28/10 at 11:40am, Carlos Mennens wrote: I just installed a fresh system today with Gnome 2.6.30. It automatically installed Epiphany Epiphany Web Bookmarks too. I would like to know if I remove both of these applications, will I effect Gnome or any of it's dependancies? I wont ever use Epiphany and I don't like useless applications lingering on my system? Is there a way to purge all of it's installation existance off my new machine without messing up Gnome? pacman is smart. If you try and -R epiphany it will tell you exactly what dependencies that might break (if any) and not let you proceed. Alternatively, you can use pacman -Qi epiphany and look for the Required by information. P -- patrick brisbin
Re: [arch-general] Package signing
On Wed, 2010-04-28 at 22:03 +0800, Ng Oon-Ee wrote: On Wed, 2010-04-28 at 23:56 +1000, Allan McRae wrote: On 28/04/10 23:52, Ng Oon-Ee wrote: On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote: On 28/04/10 23:32, Aleksis Jauntēvs wrote: Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Good to see someone interested in this. Yes, the monthly forum threads were a bit tiring. I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?). The need for testers usually occurs after implementation! :) Well, it does seem like a multi-part project, so I'm sure even before a total implementation there would be bits and pieces to test (functionality in pacman, for example, that nobody would use because the rest of the supporting cast isn't there yet). Hello I also like the idea of package signing for Arch. It would really be great if someone could implement this. I would also update my system to testing just because of this development, if a new pacman version containing this feature would show up.
Re: [arch-general] Remove Epiphany Browser
On 04/28/2010 06:40 PM, Carlos Mennens wrote: I just installed a fresh system today with Gnome 2.6.30. It automatically installed Epiphany Epiphany Web Bookmarks too. I would like to know if I remove both of these applications, will I effect Gnome or any of it's dependancies? I wont ever use Epiphany and I don't like useless applications lingering on my system? Is there a way to purge all of it's installation existance off my new machine without messing up Gnome? both of them are part of epiphany. doing pacman -Rns epiphany will do the job and is not breaking gnome at all. as for your information, nothing is installed automatically without informing you. when you did pacman -S gnome (gnome is a group of packages) it listed all packages that it will installed and answering Y will do that. If you do answer N you can select what you want. -- Ionut
Re: [arch-general] Remove Epiphany Browser
On Wed, Apr 28, 2010 at 11:56 AM, Ionut Biru biru.io...@gmail.com wrote: as for your information, nothing is installed automatically without informing you. when you did pacman -S gnome (gnome is a group of packages) it listed all packages that it will installed and answering Y will do that. If you do answer N you can select what you want. I never answered 'No' to that so that is awesome information!
Re: [arch-general] kernel 2.6.33.3 freezes on boot
Le Wed, 28 Apr 2010 11:18:17 +0200, Thomas Bächler tho...@archlinux.org a écrit Which core packages have you installed that contain modules? My first answer to your post seems to be blocked (too long due to the list of packages installed). Never mind: I think the kernel26* packages were corrupted during download; when I downloaded again the tree packages and installed them, the system became OK. Thanks. signature.asc Description: PGP signature
Re: [arch-general] kernel 2.6.33.3 freezes on boot
Le Wed, 28 Apr 2010 18:08:35 +0200, didier gaumet didier.gau...@gmail.com a écrit : [...] tree packages [...] three packages signature.asc Description: PGP signature
Re: [arch-general] dual ISP: 1)cable broadband (DHCP) 2){shudder} dial-up (ppp?) Please help!
Joe(theWordy)Philbrook (2010-04-28 08:28): It would appear that on Apr 28, Rogutės Sparnuotos did say: ... wvdial will not touch any of your network related configs (only the ppp ones), so if you will not use any other tools, your broadband will be safe. At least after reboot. Good. Then I can afford 'some' empirical testing after all. ;-) From what I've found online, and what little I can remember, wvdial should be available for just about any distro. So if I keep it's set up fairly simple, I should be able to clone a successful implementation to the other Linux installed on my multi-boot laptop. So yeah, as long as you don't count set-up utilities such as wvdialconf, and if need be, minicom, I don't plan on using any other dialup tools... Since you haven't tested your modem yet, the first thing to do would be running minicom or some other serial terminal on your /dev/ttyS?, issuing the ATZ command and see if you get OK. There is no point worrying about anything else as long as you are not sure you have a working modem. wvdialconf has to be run only once. It should ask you for the telephone number, user and password. That's good to know. From what I read in the man page I was under the impression that it would only configure the modem part of the wvdial.conf and that I'd have to manually edit in the login data... I am giving no guarantees - its been a while... ... But, if you do not test dialing-up at home, it is likely that something will go wrong when you try connecting at your sister's (and there won't be any internet connection to seek help). Absolutely. That was my plan. Else I wouldn't have worried about some brain flatulence causing me to accidentally have the Ethernet cable connected, while wvdial was active. I suppose you've setup your broadband in either rc.conf or netcfg. If that is the case, know that these setups are Archlinux specific and there is basically no software which will touch these. So you always get what you have specified in rc.conf after a reboot. And you _can_ have lots of modems and lots of ethernet cables connected to you computer, and still have your broadband working. With most setups, data packets to the internet go through the default route (try running 'route'), which is changed after a successful pppd connection and changed back after it closes (this is not wvdial specific). -- -- Rogutės Sparnuotos
Re: [arch-general] Package signing
On Wed, Apr 28, 2010 at 10:39 AM, Allan McRae al...@archlinux.org wrote: On 28/04/10 23:32, Aleksis Jauntēvs wrote: Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Good to see someone interested in this. I suggest you join the pacman-dev list where all discussion about pacman development occurs. There is also some code floating around that has started to implement this. This is my gpg branch containing those patches - http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg . Hi, Allan and Aleksis. I was thinking about this problem for sometime and the more complex part is the key distribution and trusting. Now I maybe came to something usefull. I'm thinking about a two way signing process. The dev signs the package and send it to the server. The server would have a script or a cron job to verify if the signature is valid and is from someone trusted [1]. If so, the original signature is discarded and a new one is made, with an official Arch key. So the problem of distributing keys is solved. We just need to distribute and trust the official public key of Arch. If some new developer comes to the team, its digital fingerprint is added to the list of trusted devs. If someone is removed, its fingerprint is removed. The users will trust in anything the server has signed, because the physical access to the private key is kept safe (so we hope :)). If some developer loses the confidence in his key, he can generate another and send the fingerprint to the admin, so it can be added toe the trusted list. I am willing to help with any efforts in this area. I'm already subscribed in pacman-dev and if this discussion pops up there, count me on. [1] - there should be a list of fingerprints of trusted devs, only writeable by a few admins. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto ---
Re: [arch-general] Package signing
On Wed, 28 Apr 2010 14:18:02 -0300, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: Hi, Allan and Aleksis. I was thinking about this problem for sometime and the more complex part is the key distribution and trusting. Now I maybe came to something usefull. I'm thinking about a two way signing process. The dev signs the package and send it to the server. The server would have a script or a cron job to verify if the signature is valid and is from someone trusted [1]. If so, the original signature is discarded and a new one is made, with an official Arch key. So the problem of distributing keys is solved. We just need to distribute and trust the official public key of Arch. If some new developer comes to the team, its digital fingerprint is added to the list of trusted devs. If someone is removed, its fingerprint is removed. The users will trust in anything the server has signed, because the physical access to the private key is kept safe (so we hope :)). If some developer loses the confidence in his key, he can generate another and send the fingerprint to the admin, so it can be added toe the trusted list. I am willing to help with any efforts in this area. I'm already subscribed in pacman-dev and if this discussion pops up there, count me on. [1] - there should be a list of fingerprints of trusted devs, only writeable by a few admins. Why not just use openssl instead of gpg then? You have a root cert which sings the individual pub keys of every dev. To verify the packages users just have to trust the root cert. This does even support some kind of revoke etc.. (you could even sign the root cert by an external entity like cacert to make it even more secure. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] Package signing
On Wed, Apr 28, 2010 at 13:18, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: I'm thinking about a two way signing process. The dev signs the package and send it to the server. The server would have a script or a cron job to verify if the signature is valid and is from someone trusted [1]. If so, the original signature is discarded and a new one is made, with an official Arch key. This is pretty sensible, but I think that the second step would preclude having a passphrase on the key, as it would have to be called from a script. Another way to do it might be to have the upload verified by sender key and then have the uploader sign the repo db (during the db-update step probably?). We'd have to have a keyring, but with this method even if the server is compromised the db is safe from tampering, since the keyring is signed by the highest-trust key (phrak, presumably), and that lists the keys which are allowed to sign the repo itself, so there's no way to insert untrusted keys into the keyring or repo. Perhaps the keyring package could require double-signing to also prevent an attack where phrak gets hacked again and loses his key :)
Re: [arch-general] Package signing
On 28.04.2010 19:18, Denis A. Altoé Falqueto wrote:
I'm thinking about a two way signing process. The dev signs the
package and send it to the server. The server would have a script or a
cron job to verify if the signature is valid and is from someone
trusted [1]. If so, the original signature is discarded and a new one
is made, with an official Arch key.
If you do it that way you wouldn't have to sign the uploaded packages.
I'd publish a list of developers' keys and the user has to add and trust
(in GPG terms) those keys. If he trusts them pacman installs packages
singed by those keys or keys that can be trusted because they have been
signed by them (GPG's web of trust). Otherwise if the (untrusted) sig
can be verified pacman could ask and if the sig is broken it could abort.
If you do it that way you can also add URLs to binary packages to the
AUR and let pacman download them if you trust the sig.
CC welcome.
--
Florian Pritz -- {flo,bluewi...@server-speed.net
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Package signing
On Wed, Apr 28, 2010 at 2:25 PM, Pierre Schmitz pie...@archlinux.de wrote: On Wed, 28 Apr 2010 14:18:02 -0300, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: Hi, Allan and Aleksis. I was thinking about this problem for sometime and the more complex part is the key distribution and trusting. Now I maybe came to something usefull. I'm thinking about a two way signing process. The dev signs the package and send it to the server. The server would have a script or a cron job to verify if the signature is valid and is from someone trusted [1]. If so, the original signature is discarded and a new one is made, with an official Arch key. So the problem of distributing keys is solved. We just need to distribute and trust the official public key of Arch. If some new developer comes to the team, its digital fingerprint is added to the list of trusted devs. If someone is removed, its fingerprint is removed. The users will trust in anything the server has signed, because the physical access to the private key is kept safe (so we hope :)). If some developer loses the confidence in his key, he can generate another and send the fingerprint to the admin, so it can be added toe the trusted list. I am willing to help with any efforts in this area. I'm already subscribed in pacman-dev and if this discussion pops up there, count me on. [1] - there should be a list of fingerprints of trusted devs, only writeable by a few admins. Why not just use openssl instead of gpg then? You have a root cert which sings the individual pub keys of every dev. To verify the packages users just have to trust the root cert. This does even support some kind of revoke etc.. (you could even sign the root cert by an external entity like cacert to make it even more secure. I didn't understand your reasoning completely, so what follows may be flawed. Could you expand it a little? It seems that openssl can sign a digest (probably a sha or sha1) and it can verify it, but it needs access to the private key to do the signing and the public key to do the verification. You wrote about signing public keys of developers. This signed pk`s would be distributed over to the users? I was thinking in something that would isolate the users from the changing group of developers. This could also cause problems when downloading some package that depends on a public key that was not downloaded yet. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto ---
Re: [arch-general] Package signing
On Wed, Apr 28, 2010 at 14:32, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: This could also cause problems when downloading some package that depends on a public key that was not downloaded yet. Adding the keyring to the same rule that prompts you to upgrade pacman before anything else might make sense here.
Re: [arch-general] Remove Epiphany Browser
On Wed, Apr 28, 2010 at 11:59:30AM -0400, Carlos Mennens wrote: On Wed, Apr 28, 2010 at 11:56 AM, Ionut Biru biru.io...@gmail.com wrote: as for your information, nothing is installed automatically without informing you. when you did pacman -S gnome (gnome is a group of packages) it listed all packages that it will installed and answering Y will do that. If you do answer N you can select what you want. I never answered 'No' to that so that is awesome information! The GNOME article[1] in the ArchWiki also lists several other packages you may not need or want, such as gnome-themes or gnome-backgrounds. [1] http://wiki.archlinux.org/index.php/GNOME#Installation pgpvJ8An2RXeB.pgp Description: PGP signature
Re: [arch-general] Package signing
On Wed, Apr 28, 2010 at 3:30 PM, Florian Pritz bluew...@server-speed.net wrote: On 28.04.2010 19:18, Denis A. Altoé Falqueto wrote: I'm thinking about a two way signing process. The dev signs the package and send it to the server. The server would have a script or a cron job to verify if the signature is valid and is from someone trusted [1]. If so, the original signature is discarded and a new one is made, with an official Arch key. If you do it that way you wouldn't have to sign the uploaded packages. I'd publish a list of developers' keys and the user has to add and trust (in GPG terms) those keys. If he trusts them pacman installs packages singed by those keys or keys that can be trusted because they have been signed by them (GPG's web of trust). Otherwise if the (untrusted) sig can be verified pacman could ask and if the sig is broken it could abort. If you do it that way you can also add URLs to binary packages to the AUR and let pacman download them if you trust the sig. Your suggestion is similar to Daenyth`s (for what I understand), so I will comment on both together. The central point is the management of the keyring. We could have a single key that all developers share, but this is troublesome as it would require some trusted channel to exchange the password (the first time and in the event of it changing). This approach is what others big distributions do, but the have a different structure than ours. We could have a keyring with all the trusted keys of the developers, but this could bring some problems as the keyring should be very well synchronized with the official one. Including a rule to upgrade the keyring package before others, as pacman. This requires intervention on user`s systems, so I think that it should be avoided, if possible. My idea tries to give the best of both worlds. The management of trusted devs would be made by a few admins and users would just be exposed to an official Arch key that would change just a few times, if it is not compromised. One weak point is the passphrase for the Arch key. It should not be handed over to every dev [1] and should not be used in command line scripts parameters or the cron job. It can be stored in some secure file and applied with gpg`s --passphrase-file filename or --passphrase-fd file descriptor. So, the effective user of the script would have access to read the passphrase file, but the real user would not. Maybe this is a little overkill, but CC are very welcome :) [1] Maybe I`m just too paranoid with the dev team, but I don`t think that all of them should have the passphrase (if I were a dev, I wouldn`t want to have it). We have seem the group expanding and losing components. No offence intended. -- --- Denis A. Altoe Falqueto ---
Re: [arch-general] Package signing
Am 28.04.2010 19:18, schrieb Denis A. Altoé Falqueto: I was thinking about this problem for sometime and the more complex part is the key distribution and trusting. Now I maybe came to something usefull. Finally, someone realizes that. The distrubution and trusting of keys is in fact the most difficult problem we are faced with. I'm thinking about a two way signing process. The dev signs the package and send it to the server. The server would have a script or a cron job to verify if the signature is valid and is from someone trusted [1]. If so, the original signature is discarded and a new one is made, with an official Arch key. Unacceptable. Servers get compromised way too easily (it happened in the past, and it may happen again). We'd have to store the key without a passphrase on that server for this to work. I'll never support such an approach. We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Package signing
On Thu, 2010-04-29 at 00:36 +0200, Linas wrote: Thomas Bächler wrote: We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more. You can't trust a package made with a compromised key just because it looks old. That can be falsified. Packages not affected should be resigned by another developer / the new developers key. I would still recompile them, though (withouth necessarily increasing the pkgrel). You might trust the date it if it was already in your local drive before the compromise date, but in such case you probably have it already installed, so you don't need to trust check it. Under which circunstances would you envision the need to trust an old, compromised signature? New install, dev for a coupl of [extra] packages has already left the team. Having to recompile everytime a dev leaves the team is additional (unnecessary) hassle IMO, especially for bigger packages (openoffice and sons, I'm looking at you).
Re: [arch-general] Package signing
On Wed, Apr 28, 2010 at 6:37 PM, Linas linas...@ymail.com wrote: I wrote about this topic ~1 month ago. You don't need PKCis or distribute the keyrings themselves. GPG supports transitive trust. The pacman keyring would be installed by default trusting on whatever keys a pacman root signature has signed (there could also be a different master key for community developers). The basic idea here is that you are not trusting the repository, but the individuals themselves. The master key -which can be kept offline and is only used when a developer joins/part- provides a basic default (people we generally trust) but a power user could reconfigure it to not accept packages signed by Pierre, because he distrusts him :), or he can add additional trusted people (a much more likely scenario) by just adding that person key to its keyring. Hi, Linas. Yes, you are right. I'm reading about the transitive trust scheme and it really solves the most of our problems. For the interested, here comes an interesting explanation: http://www.apache.org/dev/openpgp.html#wot-verifying-links About the other comments, in fact, the web of trust explained in the link is the correct implementation of what I've thought. I'll drat a workflow and return in a while. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto ---
[arch-general] perl 5.12
Is there a timeline for perl 5.12 entering testing? I realize it's an important not to be jumped into thing... but I don't see any bugs that are obviously holding it up... so I'm just curious why it hasn't entered testing yet. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [arch-general] Package signing
On 28 April 2010 15:37, Linas linas...@ymail.com wrote: [snip] Packages built by you - Add your own key. [/snip] Please no, it's way too convenient to be able to do makepkg su -c pacman -U whatever and not bother with keys or signing. You should be able to install unsigned packages, maybe with a confirmation from pacman. -- Tavian Barnes
