You are not logged in.
I've noticed two things about Arch.
1) The mirrors take ages to update, which means that sometimes pacman -Syu will pick up the packages upgraded 3-4 days ago even though you update daily.
2) Sometimes the package maintainers don't have time to update the package promptly. Now, that's fine as long as it's not an important security update.
I remember back from my slackware days that there was a mailing list slackware-security, where important security updates would be announced. My idea is that we should create a security taskforce for Arch that would post similar announcements on "arch-security".
Basically, volunteers in this taskforce would monitor all kinds of security mailing lists, feeds, etc. and notify respective developers that their package has had an important security update. Once the developer has updated the package they would post on the "arch-security" mailing list giving the prompt description of the security update and a link to the updated package (in order to fix the problem of slow mirrors). That way users who want top-notch security
can download the package and update.
If the developer doesn't respond in appropriate time (say 2 days) and the vulnerability is serious an interim updated package would be created by a trusted user in the taskforce, hosted somewhere and an appropriate post would be made on "arch-security".
I actually believe that, besides a few trusted users, the taskforce should be manned by non-developers. This is because developers already have a lot of work to do, and this could be a nice way of getting more hands working. I would be the first person to volunteer.
Before I go on and start this argument on the mailing list though, I am curious about what you, forum guys, think about this idea?
Offline
I think you'll get a positive response. I personally don't care much about security (I prefer the nothing to hide, nothing to lose approach), but if you think its worth doing, and you go ahead and do it, then its ok.
Its the people that say 'somebody should do something' that don't get far in Arch. Those that say 'I will do X' do well.
Dusty
Offline
I think this is a good idea - I wouldn't really participate or anything, because I'm not one of those security-snorting-omg-its-broken-RUN! type people... 8)
Though, I'd support anyone willing to do this...
I'd say if you start up a "task force" like this and don't have a TU in there, I'm sure someone would sponser one of the security guys as a TU.
Offline
bfinch is always whining about security, he might be interested. xerces2 might be interested too, cause he needs to prove himself. *grin*
Dusty
Offline
Well, I hope it's not _that_ bad being called "security-snorting-omg-its-broken-RUN!" type
It's not like I have some secret world-domination plans to hide, however I'd rather not have my SSH server hosed by a script kiddie or have my roommates' credit card stolen by phishing or whatever. So, in that sense I believe that security in Arch is important.
OK, let's see if there's some other comments here, and then in few days I'll get this issue upstream since I would like to have "arch-security" be an official arch mailing list, put an advert in the newsletter, etc.
Offline
like it
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
Also, I'd like to point out that the mailing list would be reserved for serious security problems, like for instance the zlib vulnerability and the recent firefox upgrades.
Offline
i wouldn't like this at all. i know arch for being bleeding edge, not patching wherever possible and requiring a compatible user. so called security issues can easily picked up from securityfocus or the like for everyone who cares. that should be changed? i'd prefer the way it is now actually.
personally i think arch is mostly run on desktops at home where a simple iptables setup suits all the user's needs. if you run it on a dedicated server you should be aware of the measures to be taken by yourself. in cases where higher security is required you don't trust binary packages anyway.
to sum up:
1) mailing list is ok, but it'd be redundant to some extend (-> bugtracker?)
2) security patches modify a release which makes it harder to get generic support
3) security related research slows ugrades down even more
all just my humble opnions of course.
I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell
Offline
kth5: those are the arguments most people use, but max_sipos isn't suggesting anythnig that would change the default Arch install (at least, he better not be! :-P). He's proposing an added service that people can opt to use if they wish. I don't think it would affect users who don't opt to use it...
Its hard to be against such a proposal. I won't use it, but it doesn't affect me if I don't use it, so if its good for somebody else, then there's nothing wrong with it.
Dusty
Offline
Dusty:
it might still turn out to gather like 100 people then trying to push security related feature requests. ![]()
I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell
Offline
Dusty:
it might still turn out to gather like 100 people then trying to push security related feature requests.
Well, if we try and formulate it as a sidebar to the current TU system, here's how I see it working.
The Security Task Force (STF) will be those people who are concerned with security and watch this stuff normally. Let's say Bob sees there's an error in libjpeg - buffer overflow, arbitrary code, the whole nine yards... Bob finds a patch and emails it to the libjpeg maintainer. Hopefully within some time threshold, the package is updated.
That's the basic working of this group. If the maintainer fails to update a package in a timely manner, this security group will build a specially updated package and put it into the AUR/community repo... so security concious users can updated to libjpeg-1.2.3.20050721 or something (random naming scheme there)...
Offline
kth5: Sorry, but I think you've got me somewhat wrong. STF (to use phrakture's acronym) would only monitor feeds that announce security updates of popular software. There would be no special arch patching or anything like that.
Let me try to explain with an example:
For instance, the info about the recent zlib vulnerability would be picked up by a person on the STF. It turns out that the maintainer of zlib has already published zlib x.y.z that fixes that vulnerability. The STF member contacts the maintainer of the zlib Arch package and informs him/her about the update. Once the update has been made, somebody posts on arch-security something like
zlib x.y.z updated
This update patches a serious security flaw in zlib, buffer overflow, etc. This package is available for download on ftp.archlinux.org/...
Users are strongly encouraged to update.
In case that the maintainer of the package cannot be reached for 2 days or so, a sort of a interim package of zlib x.y.z would be made.
What you are suggesting is that each person who runs a server or something like that should monitor some security-related website. I think this solution is better as:
- You receive e-mails, somebody else monitors stuff for you.
- Once you already receive an e-mail, there is an updated package one way or another waiting for you.
Offline
As for kth5's points 1, 2 and 3:
1) Mailing list would be for users who want to be updated about security information. How many users check the bugtracker daily? Or care to go through 100 bugs in order to find one about security.
2) Like I said, no special pathces.
3) That's why STF will do the research, without taking the time from developers.
Offline
I like the idea and feel that the greater Arch community could gain from you doing it. As long as it's optional to listen to any security recommendation made by this group I don't see why anyone would/could have an issue.
If this group were to start patching packages a few things like naming schemes would have to be sorted out to prevent overlap but it could be done.
Offline
a mailing list and/or forum thread would be nice.
Delegating security packages to a selected community group will also helps developers and may prevents problems like right now he have with the mozilla apps that are still not updated.
Offline
Something like AUR, but allowing binary + source package submitions, so developers can test them without waiting for compile time.
Offline
The Security Task Force (STF) .
I really really hope we get to use the acronym STFU for Security Task Force Users somewhere along the way. 8)
Dusty
Offline
I like this idea as well...it would help Arch to stay more secure and up to date when important security flaws are found. It's really just taking some of the workload off of the maintainers by getting more pairs of eyes out there looking for trouble.
Offline
Man this has been discussed so much it is almost painful. I personally think arch is no slower or faster than any other distro at getting security upgrade to the repos.
The main problem with this security thing is that no matter how much one may be concerned about it those people who are best to take care of it don't have the time to act as the head security force.
I say just use abs to upgrade then warn the masses via this forum and the mail list. At the same time use the web page to request the upgrade. Or even file a bug. Any bug that is marked as critical will be dealt with promptly.
AKA uknowme
I am not your friend
Offline
I personally think arch is no slower or faster than any other distro at getting security upgrade to the repos.
agreed... but some paranoid people feel that a few hours is too slow
the main thing is, even if a group like this doesn't do much, at least we can point all future security questions their way... "how does arch handle security, you ask? see the STF!"
Offline
Hm, well like I pointed out before, I don't think it is only few hours. Both due to mirrors being slow and packages not being made on time. Firefox 1.0.5, 1.0.6 perhaps?
Offline
What is "on time"? Really do you expect mirrors to update within an hour and packages to come out minutes after release? How wwould you feel if they rushed out the new package and it didn't work because of some bug that was not detected because the maintainer had no time to test it?
Like I said if you are absolutely in need of the package before the first second of release is up then you should probably take care of your own system with abs. No matter how hard arch maintainers try they will never get packages out "on time" enough for everyone.
Keep in mind that the maintainers of Arch are not paid and have other duties they must do before maintaining arch. If this is unsatisfactory then either you should inspire people to give enough so they can work full time on just arch or find an "enterprise" distro that has a fully paid staff that is on hand to answer your requests.
I don't mean to be harsh but if you want rock solid stability then using a so-called "bleeding edge" distro such as arch is not a good idea.
AKA uknowme
I am not your friend
Offline
Firefox 1.0.5, 1.0.6 perhaps?
ABS is fast as hell for that! :twisted:
Microshaft delenda est
Offline
I don't think security is something much Archers worry about...
Arch is bleeding-edge, and this is mostly incompatible with stability and security.
Those who want more security already know they should run another distro, Debian for example.
But of course, Arch is very easily maintainable as a server, because pacman is so fast and easy to use.
I think Arch needs some more polishing before concerning with security.
Perhaps with Arch 1.0 and pacman 3 ?
Offline
Arch is bleeding-edge, and this is mostly incompatible with stability and security.
I disagree. Bleeding edge packages IMHO is what enhances security. Any time code is change or modified, it becomes more difficult for crackers to get in or do something malicious because the new code has to be re-annalyzed. This takes time, and potentially discourages the asshat from proceeding.
Old packages on the other hand are easier for people to crack because the code has had more time to be annylized. Furthermore, linux has better security than windows IN PART because security issues can and usually are fixed within hours as compared to days, weeks, months, lightyears, etc with windows.
Offline