Hello, The naming for go packages seems inconsistent, I can see both go-* and golang-* on official and AUR packages, which am I meant to use as go-* seems to be more popular but according to the guidelines golang-* is what is meant to be used. So which should be used? and why are they differing? is either accepted? I do not know which to use, and I don't want to push a new package until I know, sorry for the noise for such a simple question but better do it right the first time, so I don't need to fix it in the future :) Thank you in advance, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Sat, 2023-06-17 at 21:57 +0100, Polarian wrote:
The naming for go packages seems inconsistent, I can see both go-* and golang-*
https://en.wikipedia.org/wiki/Go_(programming_language)#/media/File:Go_Logo_... Nobody says "Englishlang", "Germanlang" or "C++lang". To me "golang" sounds similar to "ching chang chong", something that isn't part of my vocabulary. But that's just me. Why not naming it "GoogleLang"? Doesn't that fit very well?
PS: "It is often referred to as Golang because of its former domain name, golang.org, but its proper name is Go." - https://en.wikipedia.org/wiki/Go_(programming_language)
On Sat, Jun 17, 2023, 21:04 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
"To me "golang" sounds similar to "ching chang chong",
Holy smokes that's racist as hell. Mods? Racist phrasing aside, The programming language here is often referred to as "Golang" because of its former domain name, golang.org, despite its proper name being Go. Golang is still widely used for specificity in searching since 'go' is often too generic of a term
On Sat, 2023-06-17 at 21:11 -0400, Tom Swartz wrote:
On Sat, Jun 17, 2023, 21:04 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
"To me "golang" sounds similar to "ching chang chong",
Holy smokes that's racist as hell.
Mods?
Hi. as already said before "ching chang chong", is not part of my vocabulary!
Racist phrasing aside, The programming language here is often referred to as "Golang" because of its former domain name, golang.org, despite its proper name being Go.
Golang is still widely used for specificity in searching since 'go' is often too generic of a term
You could honestly ask for "Google programming language"! If I google for "google programming language" the first hit I get is "An open-source programming language supported by Google" - https://go.dev IMO "googlelanguage" fits best.
On Sat, 2023-06-17 at 21:11 -0400, Tom Swartz wrote:
Holy smokes that's racist as hell.
Again, it's not part of my vocabulary! In addition it is very difficult to be more misanthropic than Google!
Hello, How come every time I post to the mailing list a argument breaks out *sigh*
Nobody says "Englishlang", "Germanlang" or "C++lang". To me "golang" sounds similar to "ching chang chong", something that isn't part of my vocabulary. But that's just me.
Why not naming it "GoogleLang"? Doesn't that fit very well?
I believe the reason it was named golang originally was because "go" is a verb, not a noun, therefore using it out of context would be confusing, so instead it was given the noun "golang" or go programming language because it avoided confusion. But now we all know of "go" as a language so "golang" was used less and less. Which brings me to the original answer, which hopefully a package maintainer can answer, which is what should I use moving forward, go or golang prefix?
Holy smokes that's racist as hell.
Mods?
This is not discord, you don't need to mention the mods for them to see it, and unlike discord the mods are more than capable of dealing with these issues. Ralf maybe be more careful about the phrases, to be honest I did not know the racial implications before reading the following: https://en.wikipedia.org/wiki/Ching_chong I guess growing up around toxic people makes it second nature when you hear it, but it is widely known as a racial slur. Also Tom, Ralf never said it with the intent to offend or hurt others, there is a difference. It doesn't make it justified but you got to bare in mind that there is a difference between maliciously assaulting another member or group of people, and someone who was simply trying to make a point, but used offensive language in doing so. Lets not start an argument over this please :) Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Jun 17, 2023 16:57:35 Polarian <polarian@polarian.dev>:
The naming for go packages seems inconsistent, I can see both go-* and golang-* on official
True, but the vast majority are using the proper guideline naming of golang-*. Maybe the rest were created before the guidelines?
and AUR packages,
Sure, but the AUR is full of garbage. I would stick to the guidelines and use golang-* (of course also including the module prefix if it's applicable as per guidelines). AUR packages can be deleted/merged if needed. - éclairevoyant
Hello,
True, but the vast majority are using the proper guideline naming of golang-*. Maybe the rest were created before the guidelines?
Maybe, but I doubt it. The package guidelines were created in 2012 which is a good 11 years ago, that would have been more than enough time to migrate or before the majority of go software, so I am not sure this is the case. But I could be wrong. I guess the only way to know for sure is to wait for a package maintainer (formerly TU) to comment on this problem.
Sure, but the AUR is full of garbage. I would stick to the guidelines and use golang-* (of course also including the module prefix if it's applicable as per guidelines). AUR packages can be deleted/merged if needed.
Not everything on the AUR is garbage. Also the same can be said about official packages, they can be renamed or changed at any point. Compared to the other guidelines, golang differs, the idea is to keep the package name as short as possible. The guidelines state "go package guidelines", not "golang package guidelines", which differs because all the other guidelines preserve the same naming, aka rust package guidelines use rust-* php uses php-* nodejs uses nodejs-* you get the point. I assume the original reason was as Ralf said, the domain was originally golang, and golang was its name, go was just its shortened name but its a verb so can be confused when using it as a noun. My point is, is go-* packages on the official repositories due to them being outdated as eclairevoyant has suggested, or are they there due to package maintainers preferring a different prefix (aka migration possibly?!!?). In other words, are the guidelines planned to be changed, or is it something else? Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Hi, when doing a command line package search for "go" it returns many unrelated packages, such as extra/evolution-bogofilter 3.48.3-1 Spam filtering for Evolution, using Bogofilter so there is a point in using "golang". OTOH, when I look at the naming scheme of the Go packages installed on my computer, I get a crisis: extra/golang-golang-x-crypto 0.0.20220830-1 Go supplementary cryptography libraries extra/golang-golang-x-net 0.0.20220826-1 Supplementary Go networking libraries extra/golang-golang-x-sys 0.0.20230208-1 Go packages for low-level interaction with the operating system extra/golang-golang-x-term 0.0.20220722-1 Go terminal and console support extra/golang-golang-x-text 0.3.3-2 Go text processing support extra/golang-golang-x-tools 0.0.20191225-2 Various packages and tools that support the Go programming language What the ...? "golang-golang"? "The name ylang-ylang is the Spanish spelling of the Tagalog term for the tree, ilang-ilang - a reduplicative form of the word ilang, meaning "wilderness", alluding to the tree's natural habitat. A common mistranslation is "flower of flowers"." - https://en.wikipedia.org/wiki/Cananga_odorata However, "golang-golang" sounds like a Chinese philosophical concept, https://en.wikipedia.org/wiki/Yin_and_yang . Given that "Go" is for "Go"ogle_language, my (mis)interpretation is, that the name scheme "golang-golang" does hide Google's company philosophy behind a faked pseudo-Asian term. Regards, Ralf
On Sun, 2023-06-18 at 08:55 +0200, Ralf Mardorf wrote:
faked pseudo-Asian
My apologies for the "double negative"/"tautology". I must have been a little emotional after reading package names starting with "extra/golang-golang-".
On Sun, 2023-06-18 at 03:47 +0100, Polarian wrote:
go was just its shortened name but its a verb so can be confused when using it as a noun.
"C" is just a letter of the alphabet ;), much likely nobody using Arch Linux does confuse the letter of the alphabet with the programming language, hence we don't call it "clang". I'm not convinced that "Go" is a verb. Maybe it's an "abbreviation". It's probably both in one. Ouch! On my machine I found: extra/clang 15.0.7-9 C language family frontend for LLVM extra/compiler-rt 15.0.7-2 Compiler runtime libraries for clang extra/intel-opencl-clang 15.0.0-1 Wrapper library around clang that can compile OpenCL C kernels to SPIR-V modules An exception!? Regards, Ralf
On Sun, 2023-06-18 at 09:27 +0200, Ralf Mardorf wrote:
"C" is just a letter of the alphabet
and/or a hex numeral system number :D. A B https://en.wikipedia.org/wiki/B_(programming_language) C
Hello,
"C" is just a letter of the alphabet ;), much likely nobody using Arch Linux does confuse the letter of the alphabet with the programming language, hence we don't call it "clang". I'm not convinced that "Go" is a verb. Maybe it's an "abbreviation". It's probably both in one.
Ouch! On my machine I found:
extra/clang 15.0.7-9 C language family frontend for LLVM extra/compiler-rt 15.0.7-2 Compiler runtime libraries for clang extra/intel-opencl-clang 15.0.0-1 Wrapper library around clang that can compile OpenCL C kernels to SPIR-V modules
An exception!?
Regards, Ralf
I'm not sure whether this is intended as a joke, but in case it's not: There's a difference between C, and Go or Rust, because C (as well as C++) is a core language of your OS, unlike Go. You've no other choice but having a C compiler on your system, but many people don't have a Go or Rust compiler installed. Thus no package using C has a name precising it's written in C (hence no package having a clang-* prefix); and nobody would want to search for C packages (unlike Go). Also, again I'm not sure whether it's a joke, but Clang is the C/C++ compiler from LLVM [1], that's why you've got packages with `clang` in their names (as well as you've got packages with `gcc` in their names). [1] https://clang.llvm.org/ Have a good day, Mirkwood
On Sun, 2023-06-18 at 08:15 +0000, paul.mirkwood wrote:
I'm not sure whether this is intended as a joke
Hi, my apologies for the bad satire. Is there a rational for naming packages "golang-golang-"* ? Probably naming packages just "go-"* is suboptimal, but actually the language is called "Go" and not "GoLang", let alone "GoLang-GoLang", https://archlinux.org/packages/?sort=&q=golang-golang&maintainer=&flagged= . Regards, Ralf
Hello,
Is there a rational for naming packages "golang-golang-"* ?
I don't know whether it's a good reason, but there's definitely a reason. There are basically two kinds of Go packages with a golang-* prefix in the official (non-AUR) Arch repos: - golang-golang-x-* packages, whose Upstream URL is from the official golang Github [1] - golang-github-* packages, whose Upstream URL come from various Github accounts [1] https://github.com/golang/ So the naming scheme differentiates between official (I assume) and non-official Go packages. This is not for the AUR though, where the naming scheme seems more arbitrary. I hope this helps, Mirkwood
I went through and checked all the go-* packages, they are all executable binaries not modules, hence they use the name of the project, which is as per guidelines. The golang-* packages seem to be using an interesting naming scheme. They do use the full module name but strip out the TLD - hence 'golang.org/x/text' becomes golang-golang-x-text, or 'github.com/alecthomas/units' becomes golang-github-alecthomas-units. It would be good to document *that* transformation in the guidelines explicitly. As for AUR packages, I believe they are also following this same pattern (regular apps use the project name, modules use the fully qualified module name with TLD omitted). AUR/golang-glide appears to violate this at first, but the naming is to distinguish from extra/glide (completely unrelated). Similar case with AUR/golang-mockery. Hence it seems even the AUR packages are following the guidelines. So for your question, Polarian, it would depend on what type package you're posting as well as if there's a naming conflict. But I do not see this varied naming as indicative of an upcoming guideline change. Besides, packages should follow the current guidelines, not speculative future ones :) - éclairevoyant
Okay, so here is the authorative answer to this thread. `golang-` is originally meant for source-dependencies in an effort to devendor upstream. This effor was abandoned in 2019 as Go modules became a thing. If you are curious about the naming scheme, see the Fedora and Debian package guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ https://go-team.pages.debian.net/packaging.html The gist of it is that the entire URL is part of the unique namespace of the package, and as people can fork dependencies it will provide a new unique namespace in the form of the full VCS source url. However, we don't do this in Arch. It's too combersome and has only been done with a large extent to the deeping packages, which we are hoping will finally be using go modules soon. As for the `go-` suffix, that is an undocumented convention someone started adopting for packages with name conficts, like yq and go-yq. -- Morten Linderud PGP: 9C02FF419FECBE16
Hello, So the TL;DR is Go packaging is currently a mess. I have realised a reoccurring theme with newer programming languages, everything is static linked creating huge binaries, and none of it is easy to package. Dynamic linking allows for dependency reuse. But for some reason Stack Overflow is flooded with warnings about "don't dynamic link because its less secure". I am far from an expert in linking but I thought that dynamic linking would be more secure because of address space randomisation, which I do not think can be replicated when all the libraries are statically linked into the executable and thus loaded into the same address space, correct me if I am wrong. The issue with static linking and modern languages is they all want to use their own package managers, I have had a few rust devs tell me to "stop packaging their applications because arch users should simply learn to use cargo install". The world is moving away from distribution packages, the time where storage space was limited and expensive is gone and therefore things will continue to become heavier and heavier for convenience. I assume the only time we should package go libraries, or libraries of any modern programming language is, in the off chance, they are dynamically linked against, or the library spits out a shared object? Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Sun, Jun 18, 2023 at 12:58:39PM +0100, Polarian wrote:
Hello,
So the TL;DR is Go packaging is currently a mess.
If this is what you managed to gather from my reply engaging further is not worth my time. -- Morten Linderud PGP: 9C02FF419FECBE16
Jun 18, 2023 07:58:39 Polarian <polarian@polarian.dev>:
I have realised a reoccurring theme with newer programming languages, everything is static linked creating huge binaries,
Bit of a myth, you're not using the entirety of everything you import, and linkers should properly handle removing unused symbols. Actually static linking might end up smaller this way (compared to installing the entire library as a separate package). Linkers have improved a lot since the last time static linking was the industry trend.
Dynamic linking allows for dependency reuse.
True but you'd be surprised how often that doesn't happen.
I am far from an expert in linking but I thought that dynamic linking would be more secure because of address space randomisation, which I do not think can be replicated when all the libraries are statically linked into the executable and thus loaded into the same address space, correct me if I am wrong.
static PIE exists.
The issue with static linking and modern languages is they all want to use their own package managers, I have had a few rust devs tell me to "stop packaging their applications because arch users should simply learn to use cargo install".
Seems like a lot of devs are anti-distro, but I personally would not like bespoke and nontested package managers vomiting all over my filesystem and leaving untrackable files. Arch users have the choice to use either (with consequences either way).
I assume the only time we should package go libraries, or libraries of any modern programming language is, in the off chance, they are dynamically linked against, or the library spits out a shared object?
Well what specifically are you planning to package? I don't think you've mentioned that yet. Abstract discussions lead to too many unspoken assumptions. - éclairevoyant
Hello,
Well what specifically are you planning to package? I don't think you've mentioned that yet. Abstract discussions lead to too many unspoken assumptions.
I was planning to package esc (go) because it was a makedepends for another go package I adopted, but for whatever reason the Makefile for that package is broken and upstream seems abandoned, therefore I won't bother packaging esc as it is also an old tool which is no longer used. I sent the initial email before I found a work around for the package by just calling go build directly.
Seems like a lot of devs are anti-distro, but I personally would not like bespoke and nontested package managers vomiting all over my filesystem and leaving untrackable files.
Well, that still happens with some packaged applications, especially non-free, they will vomit all over your home directory. Also I believe devs are anti-distro due to the fact that cross-distro packaging has taken off so much. Appimages are used a lot in the AUR now, and I know a a few people who don't even use pacman for anything more than installing flatpak and then installing all their software through flatpak. There is even distributions coming out now which rely solely on cross-distro packaging, only the base system is packaged. Ubuntu has been moving towards snap packages and flatpaks taking over the distro for years now. It has its benefits, flatpaks allow the developer themself to package the software, and they know no matter what distro it is, the package should work as it bundles the exact version of the dependencies, which also stops dependency version conflicts when you rely on older dependencies. Personally I am for distro packaging, and I am also for installing software into the filesystem. I dislike the concept of having huge isolated packages, and the idea I have to use multiple tools to update my system when with distro packaging its guaranteed to install correctly, and also a simple pacman -Syu updates the entire system. Another thing which is becoming more and more common is the absence of compile information. A few authors I have spoken to prevent you from building the source code, with certain rules such as: "This source code is provided for transparency, contributions are not welcome and you are not permitted to compile from source, please use the binary in releases" I have had conversations with these devs and the reason they list them is the following: - Dislike of the concept anyone can use their code, this is hilarious because they advertise themselves as open source but are against the idea of it being open, in other words they are more source available than open source, but like anyone sees a difference between this anymore, people keep telling me minecraft is open source becauase its written in Java menaing they can read the source code, which is wrong. - Dislikes distributions, yes this one is a big issue. A few devs now hate when I come along and found x build issue because their software doesn't build in a reproducible way, and they simply say that they do not want the package distributed by anyone other than them because they want full control. They use proprietary distribution servers, I can't remember the url but its basically like a repository which you pay I believe $10/month and it will spit out a ppa for ubuntu and a few other distro specific packages. Why be open source if you are going to fight contributions? Other devs simply state that they want their software to be managed by their buildin tools, a lot of these are unfortunately proprietary. I am seeing more and more software use proprietary "autoupdaters" which is considered by the privacy conscious community as a breach of privacy, you never want an application calling home without your permission, let alone allowing it to install whatever it likes to your system. - Time for the worst one, copy and paste install scripts. These are still quite popular but seem to be dying due to the introduction of new cross-distro tools. Remember those times when you copy a curl "https://some.url/some_script.sh" | /bin/bash ? Does anyone actively check these scripts for malicious intent? So many sysadmins just trust the author and will run these scripts as root as they vomit all over your filesystem and installing the application in the least conventional way possible, because the developer obviously never heard about the linux filesystem hierarchy and where different files are meant to be stored. These devs will not support your idea of distro packaging and will simply ask you to use their copy and paste script, which I wouldn't be surprised if it grabs your system information and makes a HTTP post request to some random URL while its doing its thing. Its becoming a right pain in the arse now, because you go to install a package from the AUR and find out that its literally just dumping the contents of upstream into /opt because upstream doesn't support packaging. Arch Linux philosophy is to keep it simple, but packaging is no longer simple, of course there is still some C/C++ software which is really nice, it uses dynamic links to easily link it against the current libraries provided by the distro, it can be built with a Makefile or cmake with ease, and it spits out a binary which can be easily installed into /usr/bin, the compiler doesn't call home for updates, the compiler doesn't try to automatic update itself, the compiler doesn't do anything you wouldn't expect, it just does what you tell it to do, not what the dev tells it to do on your behalf. I really wish software devs get their act together and start actively supporting the people trying to package their software, but unfortunately I feel that within 5 years, arch linux will cease to care about distro packaging and will aim towards flatpaks just like most other distros are currently doing. Sorry for the rant, its just getting on my nerves the amount of additional effort which has to go into every single package because of the developer fighting every step of the way.
Arch users have the choice to use either (with consequences either way).
Using pacman is the only officially supported method of installing software, which is made clear on the archwiki, I remember editing a page with it.
static PIE exists.
I forgot about PIE, I guess the benefits of dynamic linking are decreasing.
True but you'd be surprised how often that doesn't happen.
Well, most of the time it is because software don't update their damn dependencies so a lot of distros have to package 10 different versions of the same library. At least arch has the right idea of "if it doesn't compile with the latest compiler and libraries, then its not packagable", hopefully it might be the spur which forces devs to actually update their dependencies, which is very important for preventing security vulnerabilities.
Bit of a myth, you're not using the entirety of everything you import, and linkers should properly handle removing unused symbols. Actually static linking might end up smaller this way (compared to installing the entire library as a separate package).
It depends, the binaries themself will always be bigger, but if you include the libraries installed as dependencies then yeah I assume its totally resonable for the overrall size to be bigger. But imagine if everything statically linked to glibc, that would be a lot of duplication of symbols.
Linkers have improved a lot since the last time static linking was the industry trend.
Because of the fact developers and users like a simple executable, one file they can download instead of tons of shared objects, and ensuring they are all in the loaders path etc etc. I guess there is arguments for and against, static is very useful for cross distro, as everything is bundled, while dynamic is very good for distro packaging because you link against the packaged libraries. Sorry for the long rant of an email, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Projects start because they scratch some personal itch, not usually because said dev has desire to become a packager or provide tech support to strangers. Even proper documentation is rare, much less proper packaging. Preventing dependency hell via flatpak is one thing, but devs are even against nix which has mostly solved that problem - simply because it is not "their" build and so they don't want to spend time debugging. They just want to reduce variables before they offer support. That is fine, there are no SLAs here, so they are free to not-support whatever they want. Supporting users is already time consuming. But per open source code licenses, I am also free to ignore their wishes to not package some software. Anyway to get back to your example, I imagine esc [0] is the kind of tool that would be used among many packages, so maybe it would be worth packaging if it was still maintained upstream. It outputs a binary and should be amenable to packaging. But since it's been dead for years... maybe not worth. [0]: https://github.com/mjibson/esc
Hello,
That is fine, there are no SLAs here, so they are free to not-support whatever they want. Supporting users is already time consuming. But per open source code licenses, I am also free to ignore their wishes to not package some software.
Funny enough I tried to do that and I was banned from the repository for breaking code of conduct xD Turns out going against the developers wishes, even if its legal, is against code of conduct.
Anyway to get back to your example, I imagine esc [0] is the kind of tool that would be used among many packages, so maybe it would be worth packaging if it was still maintained upstream. It outputs a binary and should be amenable to packaging. But since it's been dead for years... maybe not worth.
Only package dependencies when they are needed, if they are not needed no point packaging them. A lot of the libraries are only packaged when there is a application which depends on them.
Projects start because they scratch some personal itch, not usually because said dev has desire to become a packager or provide tech support to strangers. Even proper documentation is rare, much less proper packaging.
For some projects yes, its personal, but for some they are quite large software communities, which still do not document their code, or provide support for distributors. Hell, ever try packaging google software and you are in for a whole world of pain, google developers refuse to speak to me because I am inferior to them, and how dare I ask to package one of their open source applications. Currently working on the flutter package, I would speak to google developers directly through github but I feel it would go bad if some random arch user comes and asks for their support. I posted a question on their discord server... 3 weeks ago I think and got a response yesterday I believe, basically telling me to use their install script (which pulls binaries from googles servers, and part of the disclaimer is that google will take data and has an entire privacy policy on what they take for you simply installing flutter). So yeah, flutter is needed to build flutter native apps, which means somehow I got to throw together some method of working around these issues just so we can package flutter packages. I will continue to make my intentions heard within their discord community, and hopefully eventually one of the developers will give in and offer their support, some of the developers are open source contributors as far as I am aware, so maybe I am more likely to get one of them on my side :P All distros are falling to cross-distro packaging, nixos is the only other distro which I see standing firm for distro packaging, because of their strong empathsis on repro builds, but then again nixos developers and contributors get paid a lot of money to help out, mainly funded by big tech companies. The average salery I have heard for a nixos dev is $150,000 working at a big tech exclusively to contribute to nix. Of course this differs from arch greatly, arch never pays a penny for contributions, which has its pros and cons, the staff at arch are not driven by personal gain, as they gain nothing, but at the same time so many staff have full time jobs which take away the time they could put into the distro, but then again money always corrupts, it affects people in different ways but almost everyone has a price, I am sure a kernel dev would put a NSA vulnerability in if they were paid a hefty price, which is scary thinking about it, can we trust that touvalds hasn't let a dodgy patch slide hoping no contributors will notice the vulnerable code, its not like the NSA is going to stick a comment in the codebase saying "NSA VULNERABILITY, DO NOT TOUCH!!!". Anyways I went completely off topic again. So overrall golang package naming is just the application as golang statically links the modules in and therefore pops out an executable, therefore the need to package golang dependencies is mitigated? Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On 2023-06-18 at 12:58:39 +0100, Polarian <polarian@polarian.dev> wrote:
I am far from an expert in linking but I thought that dynamic linking would be more secure because of address space randomisation, which I do not think can be replicated when all the libraries are statically linked into the executable and thus loaded into the same address space, correct me if I am wrong.
I'm also far from an expert in linking, but the very process of dyanmic lining can be subverted. I'm sure there are more, but two possibilities spring to mind immediately: (1) Dynamic linking depends on environment variables to find the dynamic libraries. Static applications are usually linked in a fairly clean environment, especially as compared to whatever happens to be there in a user environment. (2) With dynamic linking, one infected library is the same as multiple infected applications. Can you imagine what would happen if an intruder put their own version libc onto your system?
Hello,
(1) Dynamic linking depends on environment variables to find the dynamic libraries. Static applications are usually linked in a fairly clean environment, especially as compared to whatever happens to be there in a user environment.
How is that a bad thing, your PATH is an environment variable too? Is that a problem too?
(2) With dynamic linking, one infected library is the same as multiple infected applications. Can you imagine what would happen if an intruder put their own version libc onto your system?
This is what a lot of people say, but I do not believe this to be an issue and these are my reasons: Glibc is part of base, which is signed off by a trusted arch staff member, if you can't trust the arch staff then you can't use the distro simple. But even if you did get infected, how? You do not have write permissions to the lib directory, in other words, you would need to have given root permissions to a virus, in other words you have a lot more to worry about than glibc being infected, your entire system is compromised!!!! So I don't find the entire "Oh the library can be replaced with a malicious one" to be a good reason. Don't forget that a hacker can always relink a static link, so just because its bundled doesn't stop relinking of a malicious glibc library. This is also why binaries are owned by root, to stop users from modifying them and injecting malicious code. TL;DR in order for this attack to work, they would need root, and if they got root, then you have bigger fish to fry than a malicious library on your system. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Sun, 2023-06-18 at 15:24 +0100, Polarian wrote:
So I don't find the entire "Oh the library can be replaced with a malicious one" to be a good reason.
At least the one and only shared library needs to be replaced, a task that isn't that easy to do, while the 300 outdated libraries of different versions of the same library that isn't shared, suffer from countless exploits and nobody is able to oversee it. I can't stand snap, flatpack and Co.. I have to take your reasonable paranoia one step further. Even someone who builds packages in their free time for free can be bought by the NSA. On the other hand, developers of proprietary software can follow the highest ethical standards. Do you remember "Heartbleed"? We owe that to someone who has successfully completed his doctorate with this achievement. A PhD student who overestimates his skills can be worse than a traitor.
On Sun, 2023-06-18 at 16:51 +0200, Ralf Mardorf wrote:
Do you remember "Heartbleed"? We owe that to someone who has successfully completed his doctorate with this achievement. A PhD student who overestimates his skills can be worse than a traitor.
"Der Quellcode, der den Fehler aufweist, wurde am 31. Dezember 2011 von dem einzigen fest angestellten Mitarbeiter des OpenSSL-Teams aus dem Entwurfszweig in das OpenSSL-Git-Repository eingepflegt" - https://de.wikipedia.org/wiki/Heartbleed IOW he was payed for doing his "excellent" work. All those kids never programmed using plain Assembly, all of them are smartasses users of compiler languages, without any knowhow how the compiler does translate the code to Assembly.
On 19 June 2023 3:24:50 am NZST, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 2023-06-18 at 16:51 +0200, Ralf Mardorf wrote:
Do you remember "Heartbleed"? We owe that to someone who has successfully completed his doctorate with this achievement. A PhD student who overestimates his skills can be worse than a traitor.
"Der Quellcode, der den Fehler aufweist, wurde am 31. Dezember 2011 von dem einzigen fest angestellten Mitarbeiter des OpenSSL-Teams aus dem Entwurfszweig in das OpenSSL-Git-Repository eingepflegt" - https://de.wikipedia.org/wiki/Heartbleed
IOW he was payed for doing his "excellent" work. All those kids never programmed using plain Assembly, all of them are smartasses users of compiler languages, without any knowhow how the compiler does translate the code to Assembly.
What the hell are you on about? Why are you spamming this list about this irrelevant nonsense out of nowhere? How exactly is this relevant to the discussion? The Heartbeat implementation contained a buffer overflow. It was a simple bug. It wasn't caught before being merged in and it wasn't caught by any audits or fuzzing or testing - none was being done. None of this is or should be a stain on Seggleman's character. The blame for the impact of the bug lies with the widespread adoption of OpenSSL by people that assumed that it was bugfree and relied on it 100%. Everyone makes mistakes, including you. It has nothing to do with knowing ASM. Cheers, Miles.
On 18/06/2023 21:42, Miles Rout wrote:
On 19 June 2023 3:24:50 am NZST, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 2023-06-18 at 16:51 +0200, Ralf Mardorf wrote:
Do you remember "Heartbleed"? We owe that to someone who has successfully completed his doctorate with this achievement. A PhD student who overestimates his skills can be worse than a traitor.
"Der Quellcode, der den Fehler aufweist, wurde am 31. Dezember 2011 von dem einzigen fest angestellten Mitarbeiter des OpenSSL-Teams aus dem Entwurfszweig in das OpenSSL-Git-Repository eingepflegt" - https://de.wikipedia.org/wiki/Heartbleed
IOW he was payed for doing his "excellent" work. All those kids never programmed using plain Assembly, all of them are smartasses users of compiler languages, without any knowhow how the compiler does translate the code to Assembly.
What the hell are you on about? Why are you spamming this list about this irrelevant nonsense out of nowhere? How exactly is this relevant to the discussion?
The Heartbeat implementation contained a buffer overflow. It was a simple bug. It wasn't caught before being merged in and it wasn't caught by any audits or fuzzing or testing - none was being done.
None of this is or should be a stain on Seggleman's character. The blame for the impact of the bug lies with the widespread adoption of OpenSSL by people that assumed that it was bugfree and relied on it 100%.
Everyone makes mistakes, including you. It has nothing to do with knowing ASM.
Cheers, Miles.
Please stop this off-topic discussion. Consider this a warning. -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368
On 2023-06-18 at 15:24:55 +0100, Polarian <polarian@polarian.dev> wrote:
(1) Dynamic linking depends on environment variables to find the dynamic libraries. Static applications are usually linked in a fairly clean environment, especially as compared to whatever happens to be there in a user environment.
How is that a bad thing, your PATH is an environment variable too? Is that a problem too?
(2) With dynamic linking, one infected library is the same as multiple infected applications. Can you imagine what would happen if an intruder put their own version libc onto your system?
This is what a lot of people say, but I do not believe this to be an issue and these are my reasons:
Glibc is part of base, which is signed off by a trusted arch staff member, if you can't trust the arch staff then you can't use the distro simple. But even if you did get infected, how? You do not have write permissions to the lib directory, in other words, you would need to have given root permissions to a virus, in other words you have a lot more to worry about than glibc being infected, your entire system is compromised!!!!
So I don't find the entire "Oh the library can be replaced with a malicious one" to be a good reason. Don't forget that a hacker can always relink a static link, so just because its bundled doesn't stop relinking of a malicious glibc library. This is also why binaries are owned by root, to stop users from modifying them and injecting malicious code.
TL;DR in order for this attack to work, they would need root, and if they got root, then you have bigger fish to fry than a malicious library on your system.
All I'm saying is that dynamic linking has its own attack surface, and that said attack surface is larger than just ASLR. We could argue the merits of static vs. dynamic linking, but neither of us is an expert, so that argument would likely be sub-optimal. ;-)
On Sun, 2023-06-18 at 10:53 -0400, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
We could argue the merits of static vs. dynamic linking, but neither of us is an expert, so that argument would likely be sub-optimal. ;-)
That's incorrect. Everybody is an expert. It's possible to audit a single shared library. We still might have not the skills, but at least we can take a look at CVEs, e.g. by using one of Arch's audit tools. We can't do the same for all those /opt, appimages, flatpaks and snap installs.
participants (9)
-
2QdxY4RzWzUUiLuE＠potatochowder.com
-
Leonidas Spyropoulos
-
Miles Rout
-
Morten Linderud
-
paul.mirkwood
-
Polarian
-
Ralf Mardorf
-
Tom Swartz
-
é