News for hackers. Stuff that matters.
Re:BSD vs. Linux by jolmg on Friday November 30, 2018 @07:22PM (#18574060)
How about you rent a VPS, build your packages there, and set up the VPS as your own binary package repository? A $5/month ($0.0075/hr) Linode VPS comes with an SSD, and they're absurdly fast with the network. If it helps (I'm not sure where the bottleneck is most of the time), you can rent a more powerful VPS for a few hours for the build and then copy the built packages to a cheap $5/month VPS for hosting. Just don't forget to destroy the more powerful VPS once you're done. Turned off VPSes are still reserved for you so they would continue charging you for it until the hour you destroy it.

I haven't used Gentoo, but you say it can use binary packages. If it's too complicated, another option could be Archlinux. Building packages is really easy. It's just `asp export $package; cd $package; makepkg` and you'll get a $package-$version.pkg.tar.xz in the directory. If you want to modify something, just edit the PKGBUILD that asp downloaded. It's just a simple bash script with standard conventions. Once you're done modifying PKGBUILD, `makepkg` will make the package.

To make a repository, it's just a matter of putting all the .pkg.tar.xz in a directory and running `repose -J $repo .pkg.tar.xz; gpg -b $repo.db`, then hosting that directory with an http server.

Configuring the package manager to use your repo is just a matter of doing something like:

  cat >> /etc/pacman.conf << EOF
  [$repo]
  Server = $url
  EOF
EDIT: Anyone know how we can escape asterisks? The .pkg.tar.xz above is supposed to be a glob.
Re:BSD vs. Linux by pseudalopex on Friday November 30, 2018 @08:39PM (#18574441)
A single CPU core and 1 GB of RAM isn't enough for a build host.

I think DigitalOcean would support this better than Linode. You could keep the build host filesystem on a block storage volume instead of having to recreate it every time, and you could store the built packages in DigitalOcean's equivalent of S3 instead of needing a VPS just to host them.

Re:BSD vs. Linux by jolmg on Friday November 30, 2018 @09:12PM (#18574609)
I guess it depends on the individual packages. While many things can comfortably be quickly built on such hardware, I'm sure it wouldn't be enough for something like Firefox or Chromium. That can be handled by temporarily using a more powerful server.

I don't know about it being better, but you've got me curious. Linode also has block storage volumes. On using something like an S3, I wonder if that's really the best option. I don't know if it's cheaper, but it seems to be less flexible. For example, I like to have my private package repo provided on a VPN, not open to the public. I don't suppose using something akin to S3 would allow for a similar setup.

Re:BSD vs. Linux by jakeogh on Friday November 30, 2018 @08:03PM (#18574268)
Still need to compile once, but I use https://wiki.gentoo.org/wiki/Binary_package_guide#Implementi... and it saves plenty of time. Also, when I deploy a new box, I copy over the portage tree, so most of the packages are pre-built and ready to install into the chroot.
Re:BSD vs. Linux by pmoriarty on Friday November 30, 2018 @08:32PM (#18574407)
I don't trust VPS's.
Re:BSD vs. Linux by jolmg on Friday November 30, 2018 @08:42PM (#18574452)
Security sure is inconvenient. :)

But really, what's your threat model? For a VPS employee/company to mess with your packages, they'd have to be personally targeting you. If you're only worried about systematic, automated handling of all company VPS to insert malware in the ones that have package repositories, then you can probably set it up in an unusual way to evade such a program.

Re:BSD vs. Linux by pmoriarty on Friday November 30, 2018 @10:19PM (#18574878)
What about someone who's located on another VM on the same hardware that hosts mine breaking out of their VM and in to mine and compromising my packages?
Re:BSD vs. Linux by jolmg on Friday November 30, 2018 @10:58PM (#18575047)
You have to chose to trust something. If you keep falling in this rabbit hole of not wanting to trust anything, your only option will be to stay on an airgapped computer, or even ditching that for a paper notebook in case the hardware manufacturers did something. That's unless, of course, you have the time and resources to manufacture your own computer down to implementing every piece of circuitry in each microprocessor.

I think chances are pretty slim that a VPS company's vps isolation is so crappy that you have the chances of getting your vps hardware shared with someone that knows of such a gapping security hole that could be such a huge liability to the VPS company.

EDIT: Also, why would someone go out of their way to compromise a neighboring VPS, check if they, by chance, have a package repository, and insert malware in that? Who are you, that someone would think that's a good use of their time?

You know, society can't function without trust. Every person that's close to you could suddenly turn around and try to kill you, but you have to trust that they function by reason, and know that they have no reason for doing so. Locks around the world are pretty useless to keep strangers from lock-picking them and very many of them are keyed-alike. Their real reason is to simply make it a greater hassle to get to whatever they're protecting and therefore make it a less appealing target. Like so and with other methods, people implement their security by making themselves a less appealing target. Some people setup the outside of their home as a dump while building a mansion inside. These people trust robbers to act on reason.

No one has perfect security. Security is a matter of choosing what to defend against (your threat model), choosing what you can trust, and anchoring your defenses on the things you trust.

EDIT 2: I removed the paragraph on VPSes being virtual in name only. Linode apparently uses KVM.

Re:BSD vs. Linux by craftoman on Saturday December 01, 2018 @02:49PM (#18578534)
VPS providers are basically for personal use only not for enterprises. There have been multiple vulnerabilities that you could exploit another box from your environment.