I think that many users would be happy to do what you suggest if their work went back into the distribution. This is the way "collaborative" projects (like Debian, Fedora, etc.) work: you do some work, you become a developer and your contributions become part of the distribution.

1 members found this post helpful.

The license provides no information about security policies, just an "If it breaks, you are on your own". However, the fact that there is a mailing list for security advisories can make people think that there is a working security team, which is not.

Misinformation about which fixes will be ported, how will they be ported, why, when. The fact that many security fixes will not be applied because upstream hasn't, compilation is hard or because of other factors is not widely known. Misinformation of when a critical security bug won't be fixed in an old version because the patch fails to compile. Misinformation about why binary blobs are never placed in the /patch directory even when they contain exploits that are being used in the wild. And that was when the security service was working.

And my favorite. Misinformation about what happened to the community fixes that were provided when Patrick was ill and could not provide them by himself. Were they merged with the Slackware tree, or there were steps taken to fix the related vulnerabilities in the official distribution? No.

It has happened in the past (read above). As far as I know, fixes were not included in Slackware's tree.

Do you want -
(1) to work with other people to make your systems secure; or,
(2) to do nothing, and complain about not being given enough love in ancient history?

Actually, I think we already have enough data to answer that question.

I tried to update to openssl-0.9.8s with the -current slackbuild and it seems to have not broken openssh

if I spot something not working with this update, I'll report back

1 members found this post helpful.

I think you're referring to *lack* of information. *Misinformation* is *bad or wrong, or misleading*.

Not trying to be a nazi, just hoping to clarify....

cheers,

You can't just start producing updated packages and expect users to install them without having an oganization, standards, policies, etc. and without being officially recognized. Why should users trust you (or me or anyone else) ? And what happens to your/our packages when the official Slackware updates appear?

I'm not suggesting that anyone should distribute binaries. I'm suggesting that people should make posts exactly like Ponce's, which say, "It appears there's a realistic openssl vulnerability and an upstream release that corrects it; if you use Pat's SlackBuild to build it yourself, it seems to be ok"

If you use 'slackpkg upgrade', they will be replaced, which is exactly how it should be. Duh.

Actually it said:
Not something you would install on a production server at work (where security patches are most needed), for example, and sleep well. Although I respect people working to help others, this type of uncoordinated effort is not what is needed for security and updates to the base system, IMHO.

If you look at that long list of "vulnerabilities" there are actually very few that have any relevance to Slackware at all. Don't get all excited. As long as nobody updates that Google Doc with "this applies to Slackware version X and was not fixed there" I do not take it too seriously.

Eric

what will be needed, in your opinion?

remember that you're the only one in charge for the security of your installs at work, not Pat or a third party that publish advisories/fixes.

It works too under Slackware x86_64.

Thank you for pointing this out.

Users have no particular reasons to trust you (in fact, I like SlackBuilds because it allows you to build from the original source if you track it down). The problem with comunity a effort is that a) it is not official and b) your packages won´t be merged whith Slackware when the storm is over.

Correct, most vulnerabilities don´t affect Slackware or are of little impact. However, you have to think no hard if you wan´t to find worrying cases. The latest Firefox release fixes many problems tagged as "Critical" that are related to GNU/Linux, for example.

I suggest opening a sticky thread were new vulnerabilities and solutions could be discussed.

An official security team. I understand that this is not the way Slackware works, of course; I don't blame anyone, it's a matter of choice.
At work nobody will blame you if you install an official security update and things go wrong but you will be blamed if you install and update which "apparently" works and "maybe" doesn't break other programs. I don't have time to scrutinize every single line of code which goes into the system; I prefer to put the blame on someone else, if possible :-)

that's, unfortunately, is not possible with the way opensource works, lol

if you want that you should switch to commercial unices.

maybe we work in very different places

They could blame you for not using RHEL or M$!

Everybody, run: