Slackware64 & The Multilib Files. Should They Be Part of The Default Install.
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: Should The Multilib Files Be:
Included in the Default Installation?
5
4.24%
Offered as an Option during the installation?
33
27.97%
Available in /extra (not part of the installation)?
Someone asked a question like that in some other thread and Alien BOB said no, cause Pat would like to keep the 64bit port pure. Thankfully..
Some people who contacted Pat said he's considering adding PAM in 14.0 though.
Someone asked a question like that in some other thread and Alien BOB said no, cause Pat would like to keep the 64bit port pure. Thankfully..
Indeed.
When Pat releases updated gcc and glibc packages for slackware-current, I will be right on his tail releasing multilib versions of those packages.
Quote:
Some people who contacted Pat said he's considering adding PAM in 14.0 though.
Consideration is all, nothing set in stone. One of the motivators behind this idea is the fact that polkit seems to be a requirement to build future KDE versions and currently, polkit requires PAM. The choice would be, to add PAM or to remove KDE.
Having said this... one of the wicd developers, Andrew Psaltis (who happens to be a Slackware user) has used an old patch by PiterPUNK and Robby Workman to add support for shadow authentication to polkit, so perhaps there is hope. Adding polkit to Slackware is not possible at the moment, because Slackware lacks other required software.
Having said this... one of the wicd developers, Andrew Psaltis (who happens to be a Slackware user) has used an old patch by PiterPUNK and Robby Workman to add support for shadow authentication to polkit, so perhaps there is hope.
Very good news. Hope that works, but im wondering what kind of (additional) sacrifices it will require in the long run. But as long as theres hope not all is lost.
Personally, as a desktop user, i consider PAM and polkit as two additional layers of uneeded complexity on my systems.
But i know some people will disagree, especially people requiring PAM for server use.
More than Fingerprint authentication you could use some sort of LVM/Luks AES encryption on Steroids... call it "XES" , with the passphrases stored in a flashdrive :
eXtreme Encryption Standard...
Immagine this:
Everybody knows that most modern symmetric cyphers work based on iterated Feistel network runs with a nonlinear binary function layer between successive runs...
In each run, the data chunk, typically 256bits size, is permutated using huge binary transposition tables ( binary permutation matrixes ), one in each round, in an order specified by the passphrase, XORED with the passphrase, and then the result is fed to the nonlinear transform, before entering the next run...
... some sort of digital "enigma" of "Purple" only bitwise... not "character"-wise...
The present COCOM ( Coordinating Comitee for Multilateral Exports ) regulations about encyphering algorythms limitate the "strength" of a given set of cryptographic primitives ( Hash Functions Symmetric/Public Key encryption algorythms, Random Number Generators ) which can be exported to "State-Nations"...
The "strenghts" are a standardized by the NIST ( National Institute of Technology Standards ) in "drafts" like the PKCS ( Public Key Cryptography Standard ) created by the MOSSAD infiltrated nutkakes of RSA security for instance ( where are the founders of RSA from...? Is it Israel...? Oh well... Do guys at Haifa Polytechnical institute "Know" of any "trapdoor" within AES...? ... just asking ) and others alike...
Well given the FACTS that I have exposed, one can meke some assumptions :
1)The USA will only allow for exportation of Encryption technology that is within the "reach" of the brute force of their computer centers held by the NSA near Baltimore
2)It is within the grasp of an individual ( although, highly educated in stuff like Discrete Arithmetics, Geometric Algebra, Algorythmics, and C++ ) to design a set of cryptographic primitives that would simply overkill by a factor of choice the current computing power of Mankind for Centuries to come... even considering Moore's Law...
What would happen if one chooses to increase the number of rounds of AES up to 512...? and the "minimum" length of tha passphrase to 2048 bits...? and increase the degree of nonlinearity of the function between rounds...?
( beware that optimizing a permutation table of 2048x2048 to "flatten" the statistical characteristics that are used in Linear/differential cryptanalysis is *NOT TRIVIAL*... )
It would make those nice guys from the NSA pretty sad, their mighty computing power would simply prove to be useless, in face of the required work...
... but, guess what... If it is YOUR INFORMATION, YOU have the right to DECIDE whoever is allowed to disclose it... simple as that...
So... If you plan to design your own implementation of "XES", or PKCS #13... good luck with it...
More than Fingerprint authentication you could use some sort of LVM/Luks AES encryption on Steroids... call it "XES" , with the passphrases stored in a flashdrive :
eXtreme Encryption Standard...
You know... that is exactly what my test version of mkinitrd does... I have this laptop I'm typing on fully encrypted using LUKS. If I have my flash key inserted when Slackware boots, it finds the LUKS key stored on that USB key (a random 1024 characters which I told cryptsetup to use as an additional key) and uses that to unlock the LUKS volume automatically.
If I leave the USB key out, Slackware asks for a LUKS passphrase.
Someday before the next release of Slackware, I hope this patch gets added to the mkinitrd package.
If you plan to design your own implementation of "XES", or PKCS #13... good luck with it...
I certainly won't try, though one of my sons probably could do that as he is pretty good in mathematics: he works as a "quant" for derivatives in a bank, but don't tell anybody, traders as well as derivatives are not so popular nowadays lol.
I prefer to follow Edgar Allan Poe's advice as given in his novel "The Purloined Letter" (en Français : La lettre volée) and not even try to hide anything.
Anyhow I realize that there are Big Ears around us (CIA & Mossad among others) so I try not to write anything on the Internet or any other media that I wouldn't like to make public. And to make sure I remind that I never try to stay anonymous.
After all I stand by my statements and I feel that freedom of speech, which I hopefully benefit of, worth nothing if not used.
Take care,
Last edited by Didier Spaier; 01-03-2010 at 04:25 PM.
I'd appreciate that patch!
In fact I thought this scenario was already supported. In fact, this would make using Slackware on laptops even more attractive.
If I have my flash key inserted when Slackware boots, it finds the LUKS key stored on that USB key (a random 1024 characters which I told cryptsetup to use as an additional key) and uses that to unlock the LUKS volume automatically.
As long as nobody makes a dd of your USB key's content behind your back ...
@Didier Spaier: Excellent post, interesting statements (regarding not even trying to be anonymous).
In particular I share your attitude not to publish personal information that I don't want to share with the world on the net. That's why I have never subscribed to one of the social networks, like FaceBook, LinkedIn or Xing. Probably Web 2.0 is just not for me, although I used to develop web applications until only a few years ago.
Also, I encrypt all my hard discs, because on some of them I keep personal data, and I don't want to make my date too easily available to someone else in case a device gets lost or stolen.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.