Αναζήτηση:

Δε καταλαβαινω για εξηγησε μου τι εννοεις σε σχεση με την αλλαγη που εκανα.
Για το xz αλλαξα.Κακως αλλαξες υλικο για κατι που δεν φανηκε να επηρεαζει firmware η οτιδηποτε αλλο που αφορα σε υλικο, δεν φανηκε πουθενα κατι τετοιο απο τις αναλυσεις που εκανε τοσο κοσμος στην συγκεκριμενη περιπτωση.

Αν καταλαβα καλα αυτο που εννοουσε ο imitheos, αναφεροταν ουσιαστικα οτι εξ' ορισμου ολοι μας (τουλαχιστον το 99.99%) εχουμε ηδη ενα κλειστο συστημα (πιασε απο BIOS, συνεπεξεργαστες ασφαλειας στις cpu, chipsets, κτλ.) οποτε μια ευπαθεια που προεκυψε απο το xz τωρα δεν λεει τιποτα, γιατι μπορει ηδη να υπαρχουν backdoors στα συστηματα που ηδη εχουμε. Για να ξερεις οτι εισαι πραγματικα καλυμμενος, θες υλικο που να κατασκευαζεται απο εμπιστο κατασκευαστη και με 100% ανοικτες προδιαγραφες, κατι το οποιο δεν βρισκεις γενικως.

Η Poitras μαλλον εχει διαφορετικο μοντελο ασφαλειας και κινδυνου απο το δικο σου. :pΓια δωσε κανα link...

Ηξερα μια κυρια που επλενε τα ζαρζαβατικα με χλωρινη μετα το Τσερνομπιλ ;)Καλα, δε μου φαινεται απιστευτο.

Απλα για εμενα ειναι υπερβολη για καθε security flaw/backdoor που θα βγει να πας να αλλαξεις hardware. Ζυγισμα πριν απο τετοιες αποφασεις και τις περισσοτερες φορες θεωρω οτι δεν χρειαζεται.

Συγγνωμη, γιατι εκανες αυτες τις αλλαγες;

Τα private repositories μην τα κοιτας, τα public εχει σημασια. Προσπαθω να βρω στο github τα PR του χρηστη αυτου, αλλα δεν φαινεται να βρισκει κατι, εκτος αν κανω κατι λαθος εγω.

Ο,τι εγινε εγινε, καθε repository που εκανε commit ο συγκεκριμενος το ψαχνουν οι υπολοιποι devs.

Το θεμα ειναι απο τωρα και επειτα τι γινεται...

Μωρε ματια το βλεπουν, το θεμα ειναι να το πιασουν.

Οπως καταλαβαινετε ειναι γενικοτερο προβλημα το ολο θεμα.

Το οτι θα αλλαξεις το κλειδι του sshd δε σημαινει αυτοματα οτι σωζεσαι.

Κι ενα ωραιο infographic:

255110

Γιατι να φορτωνεται και η προβληματικη liblzma αφου ενημερωθηκε?Ε προφανως αν ενημερωθηκε δε θα φορτωνεται.

Αν καποιος κανει ενα καινουριο ssh key στο σερβερ του, δεν ειναι προστατευμενος απο ολο αυτο?Μαλλον οχι. Αν φορτωνεται η μολυσμενη liblzma μαζι με τον sshd, τοτε θα συνεχισει να υφισταται το backdoor.

Εν τω μεταξυ διαβαζα χθες το techrights (ενα blog που ειναι καργα αντι-Microsoft) και ελεγε ο τυπος οτι αυτο με το xz και το backdoor (και κανα 2-3 αλλα security vulnerabilities) βγηκε στον αερα για να στρεψει τα φωτα της δημοσιοτητας μακρυα απο τους χιλιαδες απατσαριστων Exchange servers που ειναι τρυπιοι: https://techrights.org/n/2024/03/31/Microsoft-Exchange-chaos-the-real-news.shtml

Δεν ξερω, τραβηγμενο μεν, αλλα δεν το αποκλειω να εχει και μια βαση αληθειας.

Οταν ομως το ρολοι σου ειναι σε localtime, τοτε η υποθεση χοντραινει και σηκωνει τσιγαρο.

:smoke::smoke::smoke:

Στους δισκους που εχω εβαλα το magician και εκανε update το filmware στους 2. Υπαρχει περιπτωση αυτο το backdoor να περασε απο το δισκο του linux στους δισκους των win??Στη μητρικη να βαλω το bios beta η οχι;;Χρειαζεται να κανω κατι αλλο;;Μαλλον πανικοβαλλεσαι χωρις ουσιαστικο λογο. Για τους δισκους δεν παιζει τιποτα. Επισης για τη μητρικη, το συγκεκριμενο backdoor δε νομιζω να εκανε κατι, αλλιως κατι θα ειχανε βρει μεχρι τωρα, αφορα Linux συστηματα.

Δεν χρειαζεται να κανεις κατι αλλο κατα τη γνωμη μου.

https://www.mail-archive.com/xz-devel@tukaani.org/msg00569.html

Τωρα βεβαια καταλαβαινουμε οτι τα μηνυματα ητανε επιτηδες γραμμενα ετσι για να ανοιξουν την πορτα στον Jian σαν co-maintainer αλλα και τοτε ρε παιδι μου πως δεν τα πηρε καποιος στο κρανιο και να μιλησει να προστατεψει τον Lasse; "Καταλαβαινω οτι εχεις προβληματα ψυχικης υγειας αλλα η κοινοτητα επιθυμει περισσοτερα". Να παει να γ.θει η "κοινοτητα"

Κατι σαν αυτο του Linus που ειχα ποσταρει παλια; :) "Δε μου γ..σαι που θελεις να γραψω κωδικα με αθλιες χακιες για να τρεχεις εσυ 12G σε 32bit επεξεργαστη επειδη βαριεσαι να αναβαθμισεις".
Δεν ειναι το ιδιο. Στον Lasse επιτιθεται ο αλλος κανονικα και του λεει «στα @@ μου οτι εχεις θεματα υγειας, το θεμα ειναι να προχωρησει το repository». Αν ηταν ο Torvalds στη θεση του, θα ειχε παει απατος ο αλλος.

Εκ των υστερων μαλλον αυτοι οι επιπλεον δυο που γραφουν ειναι αυτος ο Jia, προκειμενου ο Lasse να υποκυψει.

Για φωτηστε με λιγο. Εχω ssh στο συστημα μου τα τελευταια 16+ χρονια και η διανομη μου ενημερωσε το xz-utils στην 5.6.x εδω και ενα μηνα περιπου. Στο pc μου συνδεομαι, πλεον μονο τοπικα, μονο απο το κινητο (juicessh) η το ταμπλετ (connectbot), αλλα απο αυτο συνδεομαι πχ στο rpi, στο tvbox και στο λαπτοπ (επισης μονο τοπικα), που ολα εχουν παλιοτερη εκδοση xz-utils σιγουρα. Τι κινδυνους διατρεχω?Αν αυτο δεν εχει προσβαση απο τον εξω κοσμο, απο αυτα που καταλαβα, μαλλον εισαι οκ. Αλλα αναβαθμισε οπως και να 'χει, αν μπορεις.

Σχετικα με το τελευταιο, βρηκα αυτο πολυ ενδιαφερον:

https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/

Το burn out ειναι πραγματικο, και η ψυχικη υγεια πολυ σημαντικη, ειδικα σε κοινοτητες οπως το opensource που υπαρχουν παρα πολλοι ασχετοι με το θεμα και entitled τυποι με τοξικες συμπεριφορες.Ναι, τα διαβασα και νωριτερα αυτα τα μηνυματα. Δυστυχως μαλλον ετσι ειναι σε πολλα projects. Το σκεφτομουν οταν τα διαβαζα οτι ο Lasse μαλλον παραηταν ευγενικος και απολογητικος χωρις να χρωσταει τιποτα και ισως θα επρεπε να απαντησει σε κατι του στυλ «Ρε αει στο δ.....ο μ......α που θα μου πεις εμενα οτι κανω choke το repository».

Μωρε σε αυτη την περιπτωση το by chance ηταν σωτηριο. Αλλα ποσα ακομη by chance πρεπει να συμβουν για να βρεθουν τρυπες σε αλλο λογισμικο που μπορει να εμπιπτει σε μια τετοια περιπτωση; Το ολο σκηνικο δειχνει πολυ καλα μελετημενο σχεδιο που μαλλον εμπλεκονται παραπανω του ενος ανθρωποι και σχεδιο που εκτελειται μεσα σε μεγαλο χρονικο διαστημα, προκειμενου να κερδισει ο αλλος την εμπιστοσυνη, κτλ. Δυστυχως κατα την γνωμη μου υπαρχουν και αλλες παρομοιες περιπτωσεις που απλα δεν εχουν βγει στον αερα ακομη.

Σιγουρα σε λογισμικα που αρχιζουν και ειναι βασικα συστατικα του ολου οικοσυστηματος δεν πρεπει να εχουν 1-2 το πολυ maintainers. Πρεπει να εμπλεκονται πολλοι ανθρωποι, ακριβως λογω της κρισιμοτητας που εχουν αποκτησει.

https://fulda.social/@Ganneff/112184975950858403:


And if you are curious about the #xz #compromise, a little update on the #Debian site:

As already written, the archive processing is currently off (nothing new coming to testing/unstable/experimental, no mirror updates pushed out).

Automated build daemons for the affected architectures have been stopped, and only two of them regenerated with a clean #stable environment. They are building for the security archive only, nothing else, right now. That part is safe.

Members of the Release, FTP, Security, Build-Daemon and Sysadmin team are discussing what the next steps are. There are multiple different ways that can be taken, with different drawbacks and amounts of work involved.

Also, it is not yet fully known what the malicious code all could do, so there might be much more that needs to be done later - or not. Unknown as of now, needs the analysis of it to finish, which is not easy nor fast.


Μιλαμε για major mess η ολη ιστορια. Αλλα απο την αλλη κυριολεκτικα επειδη μιλαμε για λογισμικο που εχεις τον κωδικα, οι χρονοι αντιδρασης ηταν εκπληκτικοι και ο γενικοτερος τροπος αντιδρασης της κοινοτητας. Δεν ξερω σε αντιστοιχη περιπτωση σε κλειστο λογισμικο τι θα ειχε γινει και πως.

- - - Updated - - -

Νεοτερες πληροφοριες:


Let me reshare one more piece of information: this backdoor is an RCE,
not an authentication bypass.

https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b

Copy-pasting all the text written by Filippo Valsorda from there below.

=====
Filippo Valsorda
@filippo.abyssdomain.expert
I'm watching some folks reverse engineer the xz backdoor, sharing some
*preliminary* analysis with permission. The hooked RSA_public_decrypt
verifies a signature on the server's host key by a fixed Ed448 key,
and then passes a payload to system(). It's RCE, not auth bypass, and
gated/unreplayable.

This might be the best executed supply chain attack we've seen
described in the open, and it's a nightmare scenario: malicious,
competent, authorized upstream in a widely used library. Looks like
this got caught by chance. Wonder how long it would have taken
otherwise.

The payload is extracted from the N value (the public key) passed to
RSA_public_decrypt, checked against a simple fingerprint, and
decrypted with a fixed ChaCha20 key before the Ed448 signature
verification.

RSA_public_decrypt is a (weirdly named) signature verification
function. https://www.openssl.org/docs/manmaster/man3/RSA_public_decrypt.html
(Why "decrypt"? RSA sig verification is the same op of RSA encryption.
????‍♂)

The RSA_public_decrypt public key can be attacker-controlled pre-auth
by using OpenSSH certificates. OpenSSH certs are weird in that they
include the signer's public key. OpenSSH checks the signature on
parsing. https://github.com/openssh/openssh-portable/blob/281ea25a44bff53eefb4af7bab7aa670b1f8b6b2/PROTOCOL.certkeys#L207-L219

Here's a script by Keegan Ryan for sending a custom public key in a
certificate, which on a backdoored system will reach the hooked
function. https://gist.github.com/keeganryan/a6c22e1045e67c17e88a606dfdf95ae4

Apparently the backdoor reverts back to regular operation if the
payload is malformed or the signature from the attacker's key doesn't
verify. Unfortunately, this means that unless a bug is found, we can't
write a reliable/reusable over-the-network scanner.

Για το συγκεκριμενο λογισμικο ηταν 2 ανθρωποι μονο που υποτιθεται ο αρχικος εμπιστευτηκε τον δευτερο και του εδωσε commit access. Ειναι μια σημαντικη βιβλιοθηκη που ουσιαστικα την δουλευαν (εννοωντας τον κωδικα) 2, αντε 3-4 ανθρωποι, απο τους οποιους ο δευτερος καταχραστηκε το δικαιωμα και φυτεψε κακοβουλο κωδικα. Σε τοσο σημαντικα κομματια λογισμικου θελεις πολλους ανθρωπους και πραγματικη εμπιστοσυνη. Τι να πω...

- - - Updated - - -

Ασχετο: το verify-sif flag το εχετε;

euse -i verify-sig
global use flags (searching: verify-sig)
************************************************************
verify-sig - Verify upstream signatures on distfiles

local use flags (searching: verify-sig)
************************************************************
no matching entries found

Οι του debian stable επηρεαζονται; :p:)

Αυτη τη φορα δικαιωνονται αυτοι που λενε οτι οι παλιες εκδοσεις ειναι σταθερες. :)

Αλλα περιπτωση ομως.

Εσεις τι κανατε πειτε καi distro που εχετε.Ενα gmail (δευτερο οχι βασικο)μονο ειχα μπει οταν ειχα fedora θ αλλαξω κωδικο.

Στο Gentoo μπλοκαραν τις προσφατες εκδοσεις και τωρα εχει την 5.4.2.

Το κακο ειναι οτι το github εκοψε την προσβαση. Τα θεωρησε ολα ραδιενεργα.

Το κακο ειναι οτι ο συγκεκριμενος "κινεζος" dev ειχε συμμετασχει και σε αλλα projects, καπου αναφερουν και το openssl. :rtfm:
Και στη βιβλιοθηκη libarchive ειχε κανει. Κι εκει ψαχνονται γενικως να δουν τι θα κανουν.

Ευχαριστω για την εξηγηση! :oneup:

Οκ πες για το Gentoo, δεν υπαρχει περιπτωση και αλλες διανομες να χρησιμοποιουν το --as-needed στο linker για τα binaries τους;

Τι ακριβως κανει το as-needed...;


--as-needed
--no-as-needed
This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command
line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for
each dynamic library mentioned on the command line, regardless of whether the library
is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for
a library that at that point in the link satisfies a non-weak undefined symbol
reference from a regular object file or, if the library is not found in the DT_NEEDED
lists of other needed libraries, a non-weak undefined symbol reference from another
needed dynamic library. Object files or libraries appearing on the command line after
the library in question do not affect whether the library is seen as needed. This is
similar to the rules for extraction of object files from archives. --no-as-needed
restores the default behaviour.

Note: On Linux based systems the --as-needed option also has an affect on the
behaviour of the --rpath and --rpath-link options. See the description of
--rpath-link for more details.


Αναθεμα να καταλαβα Χριστο... :p

Μαλλον το πιο ασφαλες σε αυτη τη φαση για το xz-utils για μια διανομη ειναι να βαλει την τελευταια εκδοση που εκανε ο Lasse, την 5.4.2. Αυτο εκανε το Gentoo.

Maintainers απο αλλα repositories που εκανε commit ο τυπος ψαχνονται να δουν τι commit ειχε κανει τοτε και αν μπορει να ειναι malicious.

Πχ. libarchive: https://bugs.gentoo.org/928146

Επισης: https://boehs.org/node/everything-i-know-about-the-xz-backdoor

- - - Updated - - -

Εμφανιστηκε ο Lasse Collin, ο πρωτος developer: https://tukaani.org/xz-backdoor/

Εν τω μεταξυ αυτος ο τυπος εχει κανει commits και σε αλλα project, πχ. στο libarchive που υπαρχει και στο Gentoo.

https://bugs.gentoo.org/928146

Downgrade και εγω σε app-arch/xz-utils-5.4.2, και μαλιστα ζητησε και μερικα πακετα να γινουν rebuild μεσω του @preserved-rebuild μετα.Σιγουρα ηταν απο αυτο (το downgrade) και οχι απο προηγουμενο πακετο; Σε εμενα δεν ζητησε να γινει rebuild κατι.

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=56f0bb584949a4b8946dd5e79e0398e73aaf06e0Βλεπω οτι οι αλλες διανομες γυρισαν στην 5.4.6, ενω οι δικοι μας εδω στην 5.4.2. Γιατι ομως; Μηπως υποψιαζονται οτι μπορει να εχει γινει κατι στραβο ηδη απο την 5.4.6; Στο bug νομιζω ειδα οτι εγραψε καποιος να εμπιστευτουν μονο τις εκδοσεις που εκανε commit ο προηγουμενος developer.

Ναι, εβαλαν την τελευταια εκδοση που εκανε commit ο προηγουμενος developer. Το commit message γραφει το εξης:

app-arch/xz-utils: add/restore 5.4.2
This is the last release signed by Lasse Collin, the previous signer of xz-utils
releases.

Downgrade to this out of an abundance of caution. We are not aware of any issues
that *specifically* require this.

Για σκοτωμα ο τυπος.

Αντε μετα να ξαναεμπιστευτεις (και εμεις και οι διανομες) το xz...

Αν εχετε καποιο amd64 server με Gentoo και sshd ανοικτο, καντε αμεσα sync και downgrade το xz-utils. Περισσοτερα εδω: https://www.adslgr.com/forum/threads/1274597-Backdoor-%CF%83%CF%84%CE%BF-xz-utils-5-6-0

https://bugs.gentoo.org/928134

Προσοχη με το xz-utils, οσοι ειστε στην εκδοση 5.6.0+, καντε αμεσως downgrade. Απο αυτα που διαβασα, σε αυτες τις εκδοσεις περιλαμβανεται καποιο commit που επιτρεπει την αποφυγη του sshd authentication, αν η βιβλιοθηκη liblzma φορτωθει απο το ssh daemon.

https://xeiaso.net/notes/2024/xz-vuln/

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5005868

Δεν πετιεται τιποτα λεμε, ουτε σακουλα. :)

Σε ενα αλλο μηχανημα ειμαι σε openrc με split-usr και δεν εκανα τη μεταβαση για το merged-usr, ωστοσο τη μεταβαση στο 23.0 προφιλ την εκανα κανονικα χωρις θεμα. Συγκεκριμενα ειμαι στο default/linux/amd64/23.0/split-usrπροφιλ σε εκεινο το μηχανημα.

Εγω δεν το εκανα. Επισης ειχα θεμα με το installation μετα τα βηματα που περιγραφονται στα news (αυτο που περιγραφει ο OP σε αυτο https://forums.gentoo.org/viewtopic-t-1168016.html)

και ακολουθησα αυτο:

https://wiki.gentoo.org/wiki/Merge-usr

Ολα δουλευουν κομπλε τωρα.

Αντι για world rebuild εκανα μονο emerge -uDN @world

και ξαναεχτισε οσα πακετα ειχαν split-usr USE flag.

Σε 2 συστηματα, κανενα θεμα.

Btw καλα που διαβασα το νημα και ενημερωθηκα για το migration γιατι ξεχναω να διαβαζω τα news του gentoo :p

Μηπως δεν ειχες κανει τη μεταβαση απο split-usr σε merge-usr; Εγω ειμαι με systemd οποτε αυτο το βημα επρεπε ηδη να ειχε γινει.

Ναι σαν σχολιο το αφησα και εγω το CHOST στο make.conf μου. Για να θυμαμαι τις παλιες μερες :D
Ολα καλα και εδω με το world rebuild μετα το new profile.
Το χειροτερο μου ηταν οτι οταν τελειωσε εκανα νεο sync και μου εβγαλε version bump στην qtwebengine οποτε αλλο ενα rebuild για αυτο το τερας μετα το βραδινο build του...Το binary βαλε, μην χανεις χρονο με αυτο το πακετο.

Μας εσκισε. Τι το θελουν το world rebuild, ελεος...

Πω... :)

Χθες εκανα sync και σημερα που μπηκα, βλεπω οτι δεν υπαρχει το keyboard language switcher στο KDE. Τελοσπαντων, αφου το βρηκα και το ξαναεβαλα, ειδα οτι δεν υπαρχει πλεον το Greek extended variant:

254879

Εχω χασει κατι;

Και επιπλεον:


2024-03-22-new-23-profiles
Title Profile upgrade to version 23.0 available
Author Andreas K. Huettel
Posted 2024-03-22
Revision 1

A profile upgrade to version 23.0 is available for your architecture.
The new 23.0 profiles enable some toolchain hardening features and
performance enhancements by default, and standardize settings.
You can find the list of changes on the wiki tracking page .

We strongly advise to precisely follow the upgrade instructions found
below. The 17.0, 17.1, 20.0, and 22.0 profiles will be marked deprecated
in 2 months and removed a year later. The exact dates may depend on the
architecture, see .

Upgrade instructions

Note 1: The use of binary packages is completely optional, and also not
as much tested as the source-based upgrade path yet. If you prefer to
only use the traditional source-based installation, omit the "--getbinpkg"
parameter in all emerge invocations.

Note 2: If you have manually changed your CHOST to a value different from
what the stages and profiles set, you may have to do that in the future too.
In that case you should know what you are doing, hopefully; please read the
instructions with a critical eye then.

1. Ensure your system backups are up to date. Please also update
your system fully and depclean before proceeding.
glibc older than 2.36 and musl older than 1.2.4 is not supported anymore.

2. If you are still using one of the long-deprecated amd64 17.0 profiles
(other than x32 or musl), then first complete the migration to the
corresponding 17.1 profile. Instructions can be found at .

3. If you are currently using systemd in a split-usr configuration, then first
complete the migration to the corresponding merged-usr profile of the
same profile version. Details on how to do this can be found in the news
item .
If you are currently using openrc, migrate to 23.0 first, keeping your disk
layout. If you want to move from split-usr to merged-usr, do that afterwards.

4. Run "emerge --info" and note down the value of the CHOST variable.

5. Edit /etc/portage/make.conf; if there is a line defining the CHOST variable,
remove it. Also delete all lines defining CHOST_... variables.

6. Select the 23.0 profile corresponding to your current profile, either using
"eselect profile" or by manually setting the profile symlink.
Note that old profiles are by default split-usr and the 23.0 profiles by
default merged-usr. Do NOT change directory scheme now, since this will
mess up your system!
Instead, make sure that the new profile has the same property: for example,
OLD default/linux/amd64/17.1
==> NEW default/linux/amd64/23.0/split-usr
(added "split-usr")
OLD default/linux/amd64/17.1/systemd/merged-usr
==> NEW default/linux/amd64/23.0/systemd
(removed "merged-usr")
A detailed table of the upgrade paths can be found at . Please consult it.
In some cases (hppa, x86) the table will tell you to pick between two choices.
What you need should be obvious from your *old* CHOST value (from step 4).

7. Delete the contents of your binary package cache at ${PKGDIR}
rm -r /var/cache/binpkgs/*

8. In the file or directory /etc/portage/binrepos.conf (if existing), update
the URI in all configuration such that they point to 23.0 profile binhost
directories. The exact paths can be found in the table at , too.

9. Rebuild or reinstall from binary (if available) the following packages in
this order, with the same version as already active:
emerge --ask --oneshot --getbinpkg sys-devel/binutils
(you may have to run binutils-config and re-select your binutils now)
emerge --ask --oneshot --getbinpkg sys-devel/gcc
(IMPORTANT: If this command wants to rebuild glibc first, do *not* let it do
that; instead, abort and try again with --nodeps added to the command line.)
(you may have to run gcc-config and re-select your gcc now)
and the C library, i.e. for glibc-based systems
emerge --ask --oneshot --getbinpkg sys-libs/glibc
or for musl-based systems
emerge --ask --oneshot --getbinpkg sys-libs/musl

10. Re-run "emerge --info" and check if CHOST has changed compared to step 3.

If the CHOST has NOT changed, skip to step 13 (env-update). Otherwise,

11. Recheck with binutils-config and gcc-config that valid installed versions
of binutils and gcc are selected.

12. Check /etc/env.d, /etc/env.d/binutils, and /etc/env.d/gcc for files that
refer to the *OLD* CHOST value, and remove them.
Examples how to do this can be found in the similar procedure at .

13. Run env-update && source /etc/profile

14. Re-emerge libtool:
emerge --ask --oneshot --getbinpkg libtool

15. Just for safety, delete the contents of your binary package cache at
${PKGDIR} again:
rm -r /var/cache/binpkgs/*

16. Rebuild world:
emerge --ask --emptytree --getbinpkg @world


https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_transition
https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_timeline
https://www.gentoo.org/support/news-items/2019-06-05-amd64-17-1-profiles-are-now-stable.html
https://www.gentoo.org/support/news-items/2022-12-01-systemd-usrmerge.html
https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table
https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable#Verifying_things_work

Μηπως παραεισαι υπερβολικος; Σχολια inline.

Το εχω γραψει πολλες φορες στο παρελθον και θα το γραψω ακομη μια (οχι φυσικα οτι θεωρω τον εαυτο μου expert και η γνωμη μου εχει βαρυτητα) αλλα οι "stable" διανομες και πυρηνες ειναι η μεγαλυτερη παπαρα που εχει υπαρξει ποτε. Η αν θεωρεις υπερβολικο το "παπαρα", ειναι τουλαχιστον μεγαλη παγιδα γιατι δημιουργει misconceptions στον κοσμο. Το ελαχιστο που πρεπει να γινει ειναι να σταματησουν να λεγονται stable και να λεγονται πιο σωστα unchanging.

Δεν το ειχα σκεφτει ετσι ποτε, εχεις ενα δικιο οσον αφορα στο ονομα, αλλα αν το σκεφτεις ως ορος μαρκετινγκ, το stable ακουγεται πιο «καλο» απο το unchanging. Το τελευταιο θυμιζει βαλτωμα.

Αλλα οπως και να 'χει, θεωρω οτι καλως υπαρχουν τετοιες μη ρεουσες διανομες, προκειμενου να μην εχει καποιος ενα κινουμενο στοχο για να βγαλει το λογισμικο του. Σου λεει παρε το πακετο μου, ειναι για Debian 12, RedHat 9 η ο,τι αλλο. Τι θα σου πει, ειναι για Gentoo, αλλα θελει την ΧΥΖ εκδοση της βιβλιοθηκης για να παιξει σωστα;



Πριν πολλα χρονια, πρωτου γινει συνηθες παντου, μας αναγκασαν απο τη δουλεια να πληρωνομαστε σε λογαριασμο αντι για μετρητα και να εχουμε και web-banking (δεν θυμαμαι γιατι ηθελαν web-banking). Τοτε το web-banking ηταν σε βρεφικα σταδια ακομη και ενα 80% των τραπεζων επαιζαν μονο σε IE και ενα 15% επαιζε και σε firefox αλλα μονο σε windows. Ειχα βρει λοιπον μια τραπεζα που το web-banking της χρησιμοποιουσε ενα "hasp". Δηλαδη πληρωνες ενα ποσο και σου εστελναν ενα usb σαν flashακι που οσο ηταν συνδεδεμενο μπορουσε να μιλησει με τον firefox και να κανει την κρυπτογραφηση. Αυτο εδινε ενα binary οδηγο για linux. Οταν τον εγκατεστησα ειδα οτι δεν ετρεχε γιατι ειχε γινει link με παλαια εκδοση βιβλιοθηκης. Ευτυχως δεν ειχε αλλαξει φαινεται πολυ το ABI/API και κανοντας symlink (πχ ln -s libταδε.so30 libταδε.so.28) επαιξε σωστα.


Αυτο σου παρεχουν οι "stable" διανομες. Ενα περιβαλλον που δεν αλλαζει οποτε ξερεις οτι το proprietary software που χρησιμοποιει η εταιρια σου δεν θα σπασει αυριο. Δεν παρεχουν ουτε σταθεροτητα με την εννοια δεν κρεμαει ουτε ασφαλεια. Δεν ξερεις ποσο cringαρω καθε φορα που διαβαζω καποιον να λεει "να βαλεις debian stable γιατι εχει την καλυτερη security team στον κοσμο και διορθωνουν τα παντα". @@ μεντολες. Το να διατηρεις software σε μια διανομη και να βλεπεις τι patches χρειαζονται ειναι τεραστιο εγχειρημα σε μια rolling διανομη που το 90% της δουλειας σου την κανουν οι upstream devs. Σε μια "stable" διανομη ειναι τιτανιο εγχειρημα που δεν μπορει να λειτουργησει ποτε. Για να προλαβω αυτους που θα πουν κατι του στυλ "και γιατι δεν εχει bugs η stable διανομη μου" η "εγω το δουλευω χρονια και δεν μου εχει βγαλει το παραμικρο" και τα τρενα πηγαιναν για χρονια χωρις να συγκρουστουν (συγχωρεστε με που χρησιμοποιω ενα τοσο σημαντικο γεγονος που ειχαμε τοσους θανατους σαν παραλληλισμο). Στο 90% των περιπτωσεων απλα δεν βλεπουμε τα προβληματα. Απο τα 50Κ πακετα μιας διανομης ποσα χρησιμοποιει ο καθενας μας;
Κατανοητο το παραδειγμα με την αντιπαραβολη με τα τρενα αν και δυστυχως ηταν απο τις χειροτερες τραγωδιες που εζησε αυτος ο τοπος εδω και πολλες δεκαετιες.


Το ιδιο προβλημα εχουν και οι LTS πυρηνες. Ειναι τεραστιος ο κοπος που χρειαζεται για να διατηρηθουν και σαν να μην εφτανε αυτο καθε τοσο αυξανονται (6 LTS εχουμε αυτη τη στιγμη). Το ιδιο ισχυει και με τους stable πυρηνες.

Οι stable πυρηνες του Greg ξεκινησαν σαν μια καταπληκτικη ιδεα για να μειωθει ο κοπος των διανομων να ψαχνουν bug fixes για τους χρηστες. Οταν εκανες ενα bug fix στον πυρηνα, το tagαρες και το περνουσε στον stable πυρηνα. Αυτο δουλεψε πολυ καλα για ενα διαστημα. Οπως ειναι ομως λογικο, μετα απο ενα διαστημα, ολοι οι devs αρχισαν να τη λογικη "ρε συ αυτο μηπως ειναι σημαντικο bugfix, ας το στειλω για καλο και για κακο στην stable) και tagαραν τα παντα. Αν παρακολουθησεις την λιστα θα δεις πολλες φορες να τρεχει κοσμος πχ τον Χ.Υ.3 πυρηνα που να παιζει τζαμι και να εισαγεται καποιο bug στον Χ.Υ.4 επειδη εγιναν tag commits ελαφρα τη καρδια. Τωρα, τολμω (να ξανατονισω οτι δεν το παιζω εξπερ) να πω οτι ειναι καλυτερο να τρεχεις τον κεντρικο πυρηνα .0 του linus η ακομη και rcX πυρηνες (με X > 2) παρα να τρεχεις τους "stable" πυρηνες.

Επισης τολμω να πω πως το τοπιο θα ηταν πολυ καλυτερο αν σταματουσαν να υπαρχουν οι "stable" διανομες και πυρηνες και ειχαμε μονο τις rolling. Ειναι αλαζονικο να θεωρει ενας packager μιας διανομης οτι ξερει καλυτερο ενα software, και να γραφει αυθαιρετα patches, απο τον upstream dev του.
Δεν ξερω αν ειναι τοσο τραγικη η κατασταση με το backporting των patches στις LTS διανομες, για να το λες προφανως θα εχεις δει πραματα. Αλλα θεωρω οτι σε καθε περιπτωση, δεν ειναι καλυτερο παντα να τρεχεις την τελευταια .X εκδοση και οχι την .0 η την rc1, rc2 που λες; Για να μαρκαρει ο Linus μια εκδοση ως stable, προφανως ζυγιζει την ποσοτητα, την ποιοτητα των patches μεσα σε καθε εβδομαδα και αν θεωρει οτι τα πραματα εχουν ηρεμησει, τοτε την επομενη εκδοση την μαρκαρει stable (.0). Στην 6.8 ελεγε οτι μπορει να παιξει rc8, αλλα τελικα δεν επαιξε και βγηκε νωριτερα μια βδομαδα (απο το αν εβγαινε η rc8). Τωρα αν μεσα υπαρχει καποιο χοντρο bug, οπως πχ. αυτο με το bcachefs που αναφερθηκε παραπανω, ε, αν καποιος δεν το πηρε πρεφα, δυστυχως θα την πατησει ο πρωτος υποψηφιος. Παντου συμβαινει αυτο, λογισμικο ειναι, φυσικα και θα εχει bugs.

Και θεωρω οτι οι developers των διανομων προκειμενου να γραφουν μονοι τους τα patches για backporting απο τους νεοτερους, μαλλον θεωρουν τους εαυτους τους ενα εκκολαπτομενο Linus, αλλα λιγο δυσκολο το κοβω αυτο.

Επισης, ο κυκλος ζωης των τελευταιων LTS πυρηνων μειωθηκε, ακριβως επειδη θελει πολυ κοπο.

https://www.phoronix.com/news/Bcachefs-Move-Past-Linux-6.7

Γκουχ γκουχ.Τους γκαντεμιασες. :p

Σιγα ρε συ το δυσκολο να το πετυχεις, σερνεις το ποντικι και μονο του παει εκει. :)

Στην εικονα παραπανω, στο monitor που δειχνει, θα δεις οτι πανω αριστερα το εχει τσεκαρισμενο. Αυτο σημαινει οτι αν πας το ποντικι εκει και το αφησεις για λιγο, θα σου εμφανισει ολα τα παραθυρα.

Λοιον το εψαξα χτες αλλα δεν το βρηκα. Θα παραμεινει μυστηριο. :pΑυτο θες:

254357

Θα κλαψουνε μανουλες λετε;

254342

Σημερα που εκανα sync, μου βγηκε η προειδοποιηση για το split-usr, οτι εχω profile που ειναι systemd και δεν υποστηριζει το split-usr και εχω ενεργειες να κανω:


!!! Your current profile is deprecated and not supported anymore.
!!! Use eselect profile to update your profile.
!!! Please upgrade to the following profile if possible:

default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr

To upgrade do the following steps:

As warned about previously in a news item, systemd-255 has dropped
support for split-usr systems. All Gentoo systems running systemd will
need to be migrated to merged-usr.

Migrating to merged-usr will move all data from /bin, /sbin, and /lib
into the /usr/bin and /usr/lib directories. The directories in / are
replaced with symlinks.

To facilitate this, a new set of sub-profiles has been created, and a
script is available to perform the actual migration.

To migrate a system to merged-usr, follow this procedure:

1. Ensure your system backups are up to date. Please also update
your system fully and depclean before proceeding.

2. Install sys-apps/merge-usr.

3. Run "merge-usr --dryrun" as root to check for conflicts. These will
appear with the word ERROR at the start of the line.

4. Resolve any conflicts. This may involve deleting duplicate files. If
in doubt, seek support in a Gentoo support channel.

5. Run the merge-usr script from a root shell. Avoid running it via sudo
directly to avoid locking yourself out if an unexpected error occurs.

6. Switch to a merged-usr profile.

7. Run emerge with the --newuse or --changed-use option to rebuild
any packages that have a "split-usr" USE flag.

Αν ειναι μικρο το patch, σβησε αυτα που δε σε ενδιαφερουν. Μια δοκιμη σε εμενα στους φακελους test και test.new:

host /tmp $ ll test
total 4
0 drwxr-xr-x 2 lourdas users 60 Φεβ 20 18:02 ./
0 drwxrwxrwt 24 root root 620 Φεβ 20 18:02 ../
4 -rw-r--r-- 1 lourdas users 13 Φεβ 20 18:02 foo
host /tmp $ ll test.new/
total 4
0 drwxr-xr-x 2 lourdas users 60 Φεβ 20 18:02 ./
0 drwxrwxrwt 24 root root 620 Φεβ 20 18:02 ../
4 -rw-r--r-- 1 lourdas users 40 Φεβ 20 18:02 foo
host /tmp $ diff -uNr test test.new/
diff -uNr test/foo test.new/foo
--- test/foo 2024-02-20 18:02:22.604993875 +0200
+++ test.new/foo 2024-02-20 18:02:43.640177757 +0200
@@ -1 +1,4 @@
Hello World!
+Hello World!
+Hello World!

Το absolute path πως το εβαλες;

Το patch πρεπει να εχει relative paths απο την αρχη του φακελου του source, γιατι λογικα απο εκει το εφαρμοζει ο χρηστης. Βεβαια απο την αλλη εχεις και την παραμετρο -p στο patch:

-p NUM --strip=NUM Strip NUM leading components from file names

Δηλαδη στο παραπανω αν δωσεις patch -p2 < patch file (η -p1, δοκιμασε) ενω εισαι στο φακελο /home/jim, λογικα θα στο εφαρμοσει. Το δοκιμαζεις και βλεπεις.

Ειχατε θεμα με το boot; Ρωταω γιατι προσφατα πρεπει να εγινε stable ο grub 2.12-r1. Σημερα που ανοιξα το κυριο PC, εμπαινε σε boot loop με το που πηγαινε να ανοιξει το grub menu. Στο επομενο reboot εμπαινε στο BIOS κατευθειαν. Αλλαζοντας απο το BIOS τη σειρα εκκινησης, μπηκε κανονικα στα Windows, οποτε λεω κατι παιζει ειτε με τον ssd που εχω το Linux, ειτε με τον grub. Εκκινησα με system rescue, chroot στο gentoo και ξαναετρεξα grub-install και grub-mkconfig. Μετα μπηκε κανονικα.

Σε ολα τα υπολοιπα μηχανηματα ξαναετρεξα ενα grub-install και grub-mkconfig για σιγουρα.

Εχετε το υποψη...

Δεν με καταλαβες μαλλον. Συμφωνω με αυτο που λες, η AMD δεν πεταει τιποτα και ο,τι στοκ εχει στην ακρη το βγαζει με χαμηλοτερο clock, χωρις GPU, κτλ. Απλα οπως λεει στο βιντεο παιρνεις τον 5700 και νομιζεις οτι ειναι ενας χαμηλοτερος σε clock 5700X, ενω στην πραγματικοτητα δεν ειναι, δηλαδη σε μπερδευει στην προκειμενη περιπτωση.

Ναι, καμια αντιρρηση, μια χαρα κανει απο την πλευρα της, απλα να μην υπαρχουν αυτα τα τυπου 5700 non X που ειναι 5600G χωρις τη GPU... Φανηκε εξαλλου ολο αυτο το φαινομενο με την πληθωρα των μοντελων που εχει ανακοινωσει τους τελευταιους μηνες.

Καλα μιλαμε η AMD δεν πεταει ουτε καλαμακι, ποσο μαλλον silicon. :)

Ειδησεις:

2024-02-01-grub-upgrades
Title GRUB upgrades
Author Mike Gilbert
Posted 2024-02-01
Revision 2

When booting with GRUB, it is important that the core image and modules
have matching versions. Usually, running grub-install is sufficient to
ensure this.

On the UEFI platform, grub-install allows the core image to be placed in
two different locations:

EFI/gentoo/grubx64.efi
This is the location used by grub-install without options.

EFI/BOOT/BOOTX64.EFI
This is the location used by grub-install --removable.

On upgrades, it is common for users to mismatch the grub-install options
they used for the current and previous versions of grub. This will cause
a stale core image to exist. For example:

/boot/efi/EFI/BOOT/BOOTX64.EFI (grub 2.06 core image)
/boot/efi/EFI/gentoo/grubx64.efi (grub 2.12 core image)
/boot/grub/x86_64-efi/*.mod (grub 2.12 modules)

Booting this system using BOOTX64.EFI image would likely fail due to a
symbol mismatch between the core image and modules.

Re-runing grub-install both with and without the --removable option
should ensure a working GRUB installation.

However, this will clobber any BOOTX64.EFI image provided by other
loaders. If dual-booting using another boot loader, users must take care
not to replace BOOTX64.EFI if it is not provided by GRUB.

References:
https://bugs.gentoo.org/920708