- Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Tom K 25 Apr '07

25 Apr '07

David Rosenstrauch wrote: > Tom K wrote: >> David Rosenstrauch wrote: >>> Tom, >>> >>> I use EncFS pretty extensively, so I can assist you with testing if >>> you need. >>> >>> DR >>> >> >> Thanks David. >> >> Get it here for now: >> http://www.archlinux.org/~tom/packages/openssl-0.9.8e-3.pkg.tar.gz >> PKGBUILD and patch here: >> http://www.archlinux.org/~tom/packages/openssl/ >> >> I've asked the original reporter for details on the known >> OpenSSL/Blowfish problem, for inclusion in Arch News etc. >> >> T. > > Hi Tom. I just upgraded and tested. > > It's basically like Valient's mail said - the encrypted directory that I > made with the broken version of openssl-0.9.8e was now unreadable with > the new fixed version: > > [darose@davidrlin pr]$ encfssh .d2 d2 > EncFS Password: > Error decoding volume key, password incorrect > encfs failed > > But, like I did when we upgraded to the broken version in the first > place (http://archlinux.org/pipermail/arch/2007-March/013925.html) I > just deleted the bad encrypted directory and then recreated it. (I keep > the contents in a RCS, so it's easy for me to just pull them from there > again.) In retrospect, hat wasn't necessarily the correct thing for me > to do. Other people commented that they just remained downgraded on > openssl-0.9.8d. That avoided the bug, and let them keep using their > existing encrypted directories. But since recreating the directory was > no big deal, that worked for me. > > Anyway, after I whacked and recreated the directory, encfs seems to be > working fine. I'm able to unmount the encrypted directory and then > mount it again without a problem. > > So I think the fix is fine. Only caveat is that, like Valient said, > anyone who's created any encrypted directories using the broken version > will need to whack them and start again. You might want to reference > Valient's email and/or this Arch email thread > (http://archlinux.org/pipermail/arch/2007-March/013924.html) in whatever > communication you send about the issue. > > Hope this helps. Any further questions, or need me to do any more > testing, please feel free to write back. > > DR > > Many thanks for the comprehensive reply, David. I'm still waiting to hear from Valient regarding his tests, but I'll put the fixed package into testing anyway, with appropriate accompanying messages. T.

1 1

[arch-dev-public] Fwd: Consensus on network scripts
by James 24 Apr '07

24 Apr '07

oops, this one didnt make the ML, my bad. Anyone got any other comments? If I put these to a poll everyone would vote for their inclusion? Otherwise.. please say :) It's unfair otherwise if I don't get a chance to fix problems or respond to complaints. James ---------- Forwarded message ---------- From: James <iphitus(a)gmail.com> Date: Apr 21, 2007 8:32 AM Subject: Re: [arch-dev-public] Consensus on network scripts To: David Rosenstrauch <darose(a)darose.net> On 4/21/07, David Rosenstrauch <darose(a)darose.net> wrote: > James wrote: > > Yes, laptops are moved between wireless networks, but this does not > > mean that static configuration is inappropriate. My laptop for > > example, has long moved between home, and school/uni and a coffee shop > > I frequent. Three, unchanging networks. Most users of wireless have > > networks they frequent often like this. > > > > Look at my scripts, they're not as complex and error prone as you'd > > think. Most distros *do* have wep support in their scripts, and I see > > no reason why wpa shouldn't be afforded that same level of support. > > Arch is a different distro to "most other distributions". > > > > NetworkManager is not a solution. It's gui dependent. To use it, means > > loading up either KDE or Gnome. This is a ridiculous dependency for > > network connectivity. Developing a command line based client would > > be... nice. But, I don't have the experience to develop it, and arch > > needs better network scripts two years ago. > > Hi James. Was just reading through your email with interest. > > I also use my laptop for roaming ... and often start up the network from > the command line, instead of a UI. > > But I'm just wondering: what do you feel is wrong with arch's current > wifi network scripts? I use them (i.e., with /usr/bin/netcfg --menu) > and they don't seem to give me any problems. The current scripts: - Messy codebase, as features have been hacked in over time, without much plan or thought to the big picture. - Config syntax is messy and inconsistent. - All the logic and code is in netcfg, so nothing can be used outside of it. - As a result of the last, netcfg is *big*. Having everything in one file, as anyone knows, is nasty. - Using bash files as a configuration mechanism can be awkward, take a look through and you'll see lines of mass 'unset's trying to clear out variables. - Negligible error checking. You get failed connections that uh don't fail? - Are very difficult to track down why a profile has failed, and what could cause connection problems. - netcfg only deals with simple wireless configurations, these scripts are generic and can tackle any type of connection, given a lib/netcfg/connection/ script is written for them. My scripts are based on the current ones, but the above are all fairly big problems, albeit, many internal, so fixing and improving them, ended up becoming a rewrite of the scripts. There's other things I thought might be best to change too, like moving all network scripts to a separate package, and separating out the initscripts. > I usually just use knetworkmanager for connectivity. But on the > occasions that I need to use it from the command line, netcfg seems > quite adequate. I just set up a new profile, and then select it from > the netcfg menu. > > What do you think needs to be urgently improved about this process? It's a fine process, I just hope to bring our network scripts to a higher level of functionality, make them easier to use, more reliable, and easier to deal with when things go wrong. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

1 0

[arch-dev-public] Short hiatus
by Travis Willard 23 Apr '07

23 Apr '07

Hey guys, Well, school's done for me. Like, done-done. I'll get my diploma in June, whee! Honours Co-op Bachelor of Math, Computer Science. Anyway, enough tooting my own horn - with a couple weeks off before I start work (my first full-time, heh) the wife and I are doing a quick trip to visit people we haven't seen in a long time. We're leaving tomorrow (Monday) and won't be back until at least Saturday - so for at least that long I won't be available for what developer-work I do. I've updated what packages I can - fglrx just released a new version, and I'll hopefully get to that update before I go to bed tonight, and smb4k is out of date but berlios.de's down right now so I can't update that - might be a good thing though if somebody's going to move kde to /usr soon; wouldn't want to overlap with their work. Anyway, see you in one to two weeks. :) -- Travis

2 1

Re: [arch-dev-public] [arch] kernel 2.6.20.7, acpi changes and alsa bumped to 1.0.14rc3
by James 22 Apr '07

22 Apr '07

On 4/15/07, Tobias Powalowski <t.powa(a)gmx.de> wrote: > Hi folks, > the new kernel has acpi modules as much modularized as possible, it was > requested due to some people having problems with the monitoring modules in > the kernel. > > I have written a small wiki about the acpi modules, you need to add them to > your MODULES=() array in rc.conf. > Why wasnt this put into testing first at least? As we can see from the thread in [arch], we've already come across one person whose fan is controlled via acpi... and had an overheat as a result. Secondly, is modularising them really a solution? - You could have tracked down which one exactly is causing the problem, and modularised that - Or heaven above, file a bug upstream at LKML. - If this is a real problem, then other distros would have done the same, and you should have found their autodetection scripts before doing this here. this is going to annoy more people than it is going to fix problems for, and this is unacceptable when there's other solutions available. and... what was the bug? can't find it on the bug tracker. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

2 2

[arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Judd Vinet 21 Apr '07

21 Apr '07

Begin forwarded message: Date: Tue, 17 Apr 2007 23:32:26 -0700 From: "Valient Gough" <valient(a)gmail.com> To: jvinet(a)zeroflux.org Subject: OpenSSL 0.9.8e has serious bug I've had reports from a couple users of Arch Linux that EncFS is unable to access their existing encrypted filesystems after upgrading Arch packages. The problem is that OpenSSL 0.9.8e has a known problem with Blowfish encryption which makes it incompatible with any other versions of OpenSSL. EncFS users will not be able to read filesystem which use Blowfish with key length > 128 bits, and if they create a new filesystem when using OpenSSL 0.9.8e, then they will not be able to access their filesystem when using the next release of OpenSSL with that bug fixed. See: http://cvs.openssl.org/chngview?cn=15978 regards, Valient

4 4

[arch-dev-public] DistroWatch blurb
by Roman Kyrylych 21 Apr '07

21 Apr '07

Just wanted to remind the old topic http://bbs.archlinux.org/viewtopic.php?id=16767 because IMHO our DistroWatch blurb is still not as good as it could. For example it has "i686-optimized" but doesn't mention x86_64. There was http://wiki.archlinux.org/index.php/New_distrowatch_blurb where some nice proposed descriptions were collected, but it's deleted now (don't know when it happened). Suggestions? -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] Arch project management?
by Jason Chu 20 Apr '07

20 Apr '07

A lot of people have been saying that quality control in Arch has gone down the crapper (gotten worse, for the non-native english speakers). Obviously we can't test everything on everyone's machine or even test all the features of all of our packages, so what can we do? Someone suggested that we have someone who manages quality control. I don't like thinking of it as a procedural problem, so I'm going to phrase it differently. I think we need someone who makes sure that things don't get forgotten, by the developers and by the community. Someone to prod the devs and the community to test things and make sure things don't get lost. Roman already does this very very well for the bug tracker. Since we hired a bug hunter, bugs get addressed^H^H^H^H^H^H^H^H^Hassigned very quickly. What if we had the same thing for the larger/more important packages, like kernel26, glibc, apache, everything in core? The idea isn't to just throw process at the problem, but to be a little more organized in our package verification. I don't care how the organizer does it either, just as long as they make sure that people are happy with changes before they go into current/extra. I'm not suggesting any of the developers do this either, we need someone new who isn't maintaining packages, already busy with Arch developer stuff, and is active in the community. Everyone has 1 week to get their comments in before I start looking. Jason

5 6

[arch-dev-public] very outdated mirror(s)
by Roman Kyrylych 20 Apr '07

20 Apr '07

Hi! I'd like to discuss issues with mirrors being very out-of-date. ftp://ftp.nethat.com/pub/linux/archlinux/ was last updated on 2007-03-27 Can there be some way to make tracking such things easier? For example, Ukrainian mirror has {current,extra,unstable,testing,community}.lastsync files with content like: community synced at: 04/20/07 01:10 -- Roman Kyrylych (Роман Кирилич)

2 1

Re: [arch-dev-public] [Fwd: Fw: OpenSSL 0.9.8e has serious bug]
by Tom K 20 Apr '07

20 Apr '07

Valient Gough wrote: > > Hi Tom, > > I don't know if there is any tracking of OpenSSL bugs. While testing > out user reports of 0.9.8e incompatibility, I narrowed it down to an > OpenSSL problem and sent a simple test case to the OpenSSL mailing list. > > http://www.mail-archive.com/openssl-users@openssl.org/msg48671.html > > I haven't dug through OpenSSL to determine the entire extent of the > problem. I believe it causes Blowfish to use 128-bit encryption no > matter what key length you specify. > > Valient > Thanks for getting back to me. I would be grateful if you could test my patched build, available here: http://www.archlinux.org/~tom/packages/openssl-0.9.8e-3.pkg.tar.gz PKGBUILD and patch here: http://www.archlinux.org/~tom/packages/openssl/ T. P.S. I've already posted this on our public dev list, but as you may not be a subscriber, I'm sending it to you directly also.

1 0

[arch-dev-public] Consensus on network scripts
by James 20 Apr '07

20 Apr '07

Hey, http://wiki.archlinux.org/index.php/Network_Scripts I've been pushing these repeatedly, with only meager interest shown by others. Given a little bit of documentation, I think they're almost ready for me to unleash and publicise for further testing. That said.... before I put the time into writing the docs, closing some known bugs, and publicising them more, I'd like to know what everyone thinks and get some 'approval' for them. Some sort of OK, we'll adopt and implement these given A, B and C are done. I don't know what the process is for this, nor do I think we've ever had/needed one as discussion should be fine, so bear with me. I realise that not everyone wants to install these and try them, so I'll just outline the major outward changes in order of what might cause debate. New features and improvements are listed on the wiki. - All network scripts moved from 'initscripts' to 'network', a separate package - /etc/rc.d/network retains ALL functionality that it has had previously, except it's wireless. - /etc/rc.conf network syntax remains, except it's wireless. - All wireless functionality now exists within the profiles. - /etc/network-profiles is no more, moved to /etc/network.d - profile syntax has changed, now using an ini format. See wiki for examples. - completely rewritten and cleaned up netcfg - netcfg menu support separated out from netcfg - network profiles moved from /etc/rc.d/network to /etc/rc.d/net-profiles Beyond that.... the changes are internal. Some minor cleanups and bugfixes in /etc/rc.d/network, and the rest of the changes are within netcfg and the Arch profile system. If you're interested in testing... there's details on the wiki, i've got a repo up in my public_html on archlinux.org. Feel free to put bugs on the tracker, or send via email. Patches to latest git are always welcome. Anything to say, add, suggest, please do, +1's great, +>1's better, -1's only with a good fair explanation. Thanks! James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

5 8