We don't have a CGO in our project. We want libc and we value it because
it's a gold standard which makes things stable and predictive. After all,
container must just work, so we focus on our services other that testing
and troubleshooting some side technology.
For issues you can take a look at their github and this will also give you
some basic idea what process of mitigation is like. You will not find
issues older than 2019 however.
воскресенье, 20 декабря 2020 г. в 21:53:08 UTC+3, ntr...@gmail.com:
> Most of the issues presented here are only relevant for CGO and other
> programming languages, not Go.
>
> Also, could anyone share references about the security problems in Alpine?
> I may say Windows is more secure and faster than Linux (or the opposite),
> but without any evidence, it is just a conjecture.
>
> Some of the advantages from Alpine for me:
>
> * Image size. My internet connection is 1mbps (my country sucks) and I
> usually have to share it with 15 other devices, so 100MB is a lot for me.
>
> * Simplicity. It is easier to become a US citizen than having your package
> in the Debian stable branch. Haha just kidding, but it is pretty hard and a
> lot of organizational complexity happens there [1]. If you use apt to
> install some tools, you will get old releases (which is good for end-users
> or servers, they are really well tested, but we are developers, and in
> production you should probably use `scratch` with distributed tracing,
> logging, etc...). Mirroring Debian repositories takes a lot of storage
> space (the last time I did, it was ~250GB) because you have to download
> every release and you need special tools [2] for that (you can setup a
> proxy instead, but internet access is required most of the time), also the
> mirror gets invalidated every in a while, so you are forced to update or
> you will end up with a broken environment. For an Alpine mirror you only
> need rsync and some options for excluding unneeded releases, so less
> storage space is required (3.12 is <20GB). (Again, my country sucks, so I
> need a mirror, or I will wait more than 30 minutes every time I have to
> install some packages).
>
> * Consistency. If your build scripts work on Alpine, they will probably
> work in any Unix (or at least Linux) environment.
>
> I don't consider deployment advantages because as I said, I prefer
> deploying my binaries with `scratch`, but if I have to use `alpine`, I
> would say:
>
> * Minimalism. It is not just only about numbers, but philosophy [3],
> Alpine keeps everything as minimal as it can, packages are usually split
> into `package`, `package-docs` (man pages),
> `package-{bash,zsh,...}-completion`, so you get what you need, no more, no
> less.
>
> * Security. The attack surface is very small and C binaries are compiled
> with some good security options.
>
> Don't take me wrong, I love Debian, it was my very first Linux
> distribution. If CGO is a requirement and musl doesn't work out of the box,
> you should choose `debian`, otherwise, I strongly recommend `alpine`.
>
> [1]: https://www.debian.org/releases/
> [2]: https://www.debian.org/mirror/ftpmirror
> [3]: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Overview
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3233217b-a8e2-4feb-b7de-018de68b2d07n%40googlegroups.com.
