4 ms·

> Installation uses HTTP to fetch a boot volume image. This is a problem with all of the suckless software and it, well, sucks.

ghshephard 10y ago
What's wrong with HTTP? I think the OpenBSD team made it clear that HTTPS does nothing for security (At least the integrity portion) of downloading stuff (which is why signify is a thing). By explicitly using a non-secure channel for transport you make it explicit that integrity must come from some other channel.
- creshal 10y ago
  Except… There is no other channel. Suckless doesn't sign their releases, nor the image download. Nor is anything in git signed. Integrity, schmintegrity ¯\_(ツ)_/¯
  - qplex 10y ago
    The other channel: read the source code yourself before compiling. This actually possible with most suckless projects since they are just a couple of hundred lines of C...
    - dTal 10y ago
      Are you familiar with the Underhanded C Contest? It's possible to maliciously tamper with C code such that you definitely wouldn't spot it with a cursory glance over, and possibly even with careful study.
      - geocar 10y ago
        Counterpoint: most underhanded C successes look like incompetence instead of malice, but still look "wrong"
        creshal 10y ago
        …to someone who spends a lot of time writing C code.
    - kbenson 10y ago
      Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads, and that the lines of code in C often correlates directly to complexity of the solution being expressed, this also assumes that an attack vector would be something obvious upon reading the code, and not hidden as a subtle bug which is hard to spot.
      - Spivak 10y ago
        > Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads Don't ignore it, that's the practically the point. This is the perfect example of "don't trust me, trust the code". From http://dwm.suckless.org/ http://dwm.suckless.org/ > Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.
        kbenson 10y ago
        > This is the perfect example of "don't trust me, trust the code". But it's not that. It's "don't trust me, trust the code as long as you're part of the select group of people that can read and understand the code given the language we use, which by the way happens to be well known to be hard to vet for subtle logic errors, which because of the nature of the language often result in segfaults (at best), or remote code execution (at worst)." Why not write it in brainfuck? They'll only change their audience by a minuscule amount compared to the original audience they could have appealed to, and they will be even more "small and elitist". I originally translated "This keeps its userbase small and elitist. No novices asking stupid questions." as "We're a tight knit group of assholes, and if you didn't take the same path in life we did there's no point in talking to you." It may be unfair to assume that's their intention, but I think it is fair to say that's what they are doing in practice.
    - startling 10y ago
      The stali source includes, among other things: * a full checkout of libressl: http://git.sta.li/src/tree/lib/libressl http://git.sta.li/src/tree/lib/libressl * a full checkout of expat: http://git.sta.li/src/tree/lib/expat http://git.sta.li/src/tree/lib/expat * two full /bins: http://git.sta.li/rootfs-x86_64/tree/bin http://git.sta.li/rootfs-x86_64/tree/bin http://git.sta.li/rootfs-pi/tree/bin http://git.sta.li/rootfs-pi/tree/bin
      - qplex 10y ago
        Emphasis on "most suckless projects". The point was that you can verify the integrity by reading the source code. The actual limits to this depend on many things.
josteink 10y ago
> > Installation uses HTTP to fetch a boot volume image. > This is a problem with all of the suckless software and it, well, sucks. If you serve things over HTTP its easier to daisy-chain it in a PXE -> iPXE kind of setup. HTTPS is not supported by most boot-ROMs. Keep your boot-image server on site and local and HTTP isn't a real world issue.
- startling 10y ago
  1) dl.sta.li is not on my site, and probably not on yours. 2) That's still suboptimal. You're giving each host on your LAN the ability to interfere with any newly-provisioned server. This is a perfect and hard-to-detect way for an attacker to pivot from "RCE on some random webapp" to "advanced persistent threat".
signa11 10y ago
> > Installation uses HTTP to fetch a boot volume image. > This is a problem with all of the suckless software and it, well, sucks. may you please elaborate on why you think fetching boot images over http is a bad idea ? fwiw, a large number of networking gear boot their line-cards with image fetched over http e.g. csco's asr-5000 etc.
- Crespyl 10y ago
  > networking gear As someone unfamiliar with that domain, this just raises more questions for me. Is there some secondary layer of code-signing/validation that happens? Is the image host always within the local network and the connection assumed trustworthy?
  - signa11 10y ago
    > Is there some secondary layer of code-signing/validation that happens? Is the image host always within the local network and the connection assumed trustworthy? some more information: basically most of the these routers etc. are 'chassis' based e.g. asr-5k is a 14u (iirc) device. depending on architecture, these generally have a bunch cards which end up doing most of the work e.g. session processing, forwarding traffic, running your routing protocols etc. etc. most of the session-processing cards don't really have any non-volatile storage media. ok, now, two of these (for redundancy purposes) are management cards. these cards are not involved in any session processing, and provide 'shell' access to the device. these are generally used to configure the device, run diagnostics etc. etc. management cards have non-volatile storage media, which end up storing various boot images. now, when a chassis is powered on, management cards are booted up first, using one of the stored images (depending on configuration). other cards (non-management) get their boot images over an internal network via http (e.g. in case of asr-5k). tldr-mode: yes, the 'network' is trustworthy, and images are present locally (in most of the cases). though it is possible to boot management cards (if your read the above longish explanation) via images over tftp/scp etc. which can be as secure / insecure as you want :) edit-001: lemme know if you need some more information, and i can see how i can make things clearer.

ghshephard 10y ago

What's wrong with HTTP? I think the OpenBSD team made it clear that HTTPS does nothing for security (At least the integrity portion) of downloading stuff (which is why signify is a thing). By explicitly using a non-secure channel for transport you make it explicit that integrity must come from some other channel.

creshal 10y ago
Except… There is no other channel. Suckless doesn't sign their releases, nor the image download. Nor is anything in git signed. Integrity, schmintegrity ¯\_(ツ)_/¯
- qplex 10y ago
  The other channel: read the source code yourself before compiling. This actually possible with most suckless projects since they are just a couple of hundred lines of C...
  - dTal 10y ago
    Are you familiar with the Underhanded C Contest? It's possible to maliciously tamper with C code such that you definitely wouldn't spot it with a cursory glance over, and possibly even with careful study.
    - geocar 10y ago
      Counterpoint: most underhanded C successes look like incompetence instead of malice, but still look "wrong"
      - creshal 10y ago
        …to someone who spends a lot of time writing C code.
  - kbenson 10y ago
    Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads, and that the lines of code in C often correlates directly to complexity of the solution being expressed, this also assumes that an attack vector would be something obvious upon reading the code, and not hidden as a subtle bug which is hard to spot.
    - Spivak 10y ago
      > Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads Don't ignore it, that's the practically the point. This is the perfect example of "don't trust me, trust the code". From http://dwm.suckless.org/ http://dwm.suckless.org/ > Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.
      - kbenson 10y ago
        > This is the perfect example of "don't trust me, trust the code". But it's not that. It's "don't trust me, trust the code as long as you're part of the select group of people that can read and understand the code given the language we use, which by the way happens to be well known to be hard to vet for subtle logic errors, which because of the nature of the language often result in segfaults (at best), or remote code execution (at worst)." Why not write it in brainfuck? They'll only change their audience by a minuscule amount compared to the original audience they could have appealed to, and they will be even more "small and elitist". I originally translated "This keeps its userbase small and elitist. No novices asking stupid questions." as "We're a tight knit group of assholes, and if you didn't take the same path in life we did there's no point in talking to you." It may be unfair to assume that's their intention, but I think it is fair to say that's what they are doing in practice.
  - startling 10y ago
    The stali source includes, among other things: * a full checkout of libressl: http://git.sta.li/src/tree/lib/libressl http://git.sta.li/src/tree/lib/libressl * a full checkout of expat: http://git.sta.li/src/tree/lib/expat http://git.sta.li/src/tree/lib/expat * two full /bins: http://git.sta.li/rootfs-x86_64/tree/bin http://git.sta.li/rootfs-x86_64/tree/bin http://git.sta.li/rootfs-pi/tree/bin http://git.sta.li/rootfs-pi/tree/bin
    - qplex 10y ago
      Emphasis on "most suckless projects". The point was that you can verify the integrity by reading the source code. The actual limits to this depend on many things.

josteink 10y ago

> > Installation uses HTTP to fetch a boot volume image. > This is a problem with all of the suckless software and it, well, sucks. If you serve things over HTTP its easier to daisy-chain it in a PXE -> iPXE kind of setup. HTTPS is not supported by most boot-ROMs. Keep your boot-image server on site and local and HTTP isn't a real world issue.

startling 10y ago
1) dl.sta.li is not on my site, and probably not on yours. 2) That's still suboptimal. You're giving each host on your LAN the ability to interfere with any newly-provisioned server. This is a perfect and hard-to-detect way for an attacker to pivot from "RCE on some random webapp" to "advanced persistent threat".

signa11 10y ago

> > Installation uses HTTP to fetch a boot volume image. > This is a problem with all of the suckless software and it, well, sucks. may you please elaborate on why you think fetching boot images over http is a bad idea ? fwiw, a large number of networking gear boot their line-cards with image fetched over http e.g. csco's asr-5000 etc.

Crespyl 10y ago
> networking gear As someone unfamiliar with that domain, this just raises more questions for me. Is there some secondary layer of code-signing/validation that happens? Is the image host always within the local network and the connection assumed trustworthy?
- signa11 10y ago
  > Is there some secondary layer of code-signing/validation that happens? Is the image host always within the local network and the connection assumed trustworthy? some more information: basically most of the these routers etc. are 'chassis' based e.g. asr-5k is a 14u (iirc) device. depending on architecture, these generally have a bunch cards which end up doing most of the work e.g. session processing, forwarding traffic, running your routing protocols etc. etc. most of the session-processing cards don't really have any non-volatile storage media. ok, now, two of these (for redundancy purposes) are management cards. these cards are not involved in any session processing, and provide 'shell' access to the device. these are generally used to configure the device, run diagnostics etc. etc. management cards have non-volatile storage media, which end up storing various boot images. now, when a chassis is powered on, management cards are booted up first, using one of the stored images (depending on configuration). other cards (non-management) get their boot images over an internal network via http (e.g. in case of asr-5k). tldr-mode: yes, the 'network' is trustworthy, and images are present locally (in most of the cases). though it is possible to boot management cards (if your read the above longish explanation) via images over tftp/scp etc. which can be as secure / insecure as you want :) edit-001: lemme know if you need some more information, and i can see how i can make things clearer.