On Sat, Jun 17, 2023, 21:04 Ralf Mardorf 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:

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!

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 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

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

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

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

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

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

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

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 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 18/06/2023 21:42, Miles Rout wrote:

On 19 June 2023 3:24:50 am NZST, Ralf Mardorf 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 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. ;-)