Packaged install and tls everywhere #94

Merged
merged 2 commits into from May 19, 2013

3 participants

@GrmpCerber

Fixes #92
Fixes #93

@skgsergio

A couple of thoughts about this pull request:

  • Cloning from HTTPS was discussed previously and this was the decision: #66 (comment) (if you are afraid of someone doing a MitM to you I think you should fix first that problem first. Cloning this repo isn't critical...)

  • Instructions for package install should not replace the old ones, for example I'm using my own debootsraped install. I'm not using the RPi Foundation image nor its mirror so for me there is no package.

@GrmpCerber

Hi skgsergio

For your second bullet, I've commited a new README combining both techniques but I've taken care to change the source URL for the wget (see below for the reason).

For the first bullet I totally disagree with you for several reasons :
1. GitHub is SSL only which means that they redirect each request made on http to it's https counterpart. This means that using GitHub http addresses is merely saving you from a single 's' character and causing a big waste of time because of the redirections & reconnections (which means that #66 is ...) :

wget http://github.com/Hexxeh/rpi-firmware.git
--2013-05-17 14:23:44--  http://github.com/Hexxeh/rpi-firmware.git
Resolving github.com (github.com)... 204.232.175.90
Connecting to github.com (github.com)|204.232.175.90|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://github.com/Hexxeh/rpi-firmware [following]
--2013-05-17 14:23:45--  http://github.com/Hexxeh/rpi-firmware
Connecting to github.com (github.com)|204.232.175.90|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/Hexxeh/rpi-firmware [following]
--2013-05-17 14:23:45--  https://github.com/Hexxeh/rpi-firmware
Connecting to github.com (github.com)|204.232.175.90|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38037 (37K) [text/html]
Saving to: `rpi-firmware.git'
  1. MitM
    if you are afraid of someone doing a MitM to you I think you should fix first that problem first.

I'm network user not operator therefor SSL/TLS is the only mean I can use to secure this risk.
Beside, if you trust your network operator to completly cover this, then you haven't underdstood the concept of WEB, AS, routing, country, borders, politics, spying & industrial spying, ...
(sidenote : I know SSL/TLS is not bulletproof (see Diginotar incident))

  1. Cloning this repo isn't critical...

Well, we are talking about a repo that holds firwmare for a server which means very low level binaries. Any bad guy able to MitM, would enjoy easy eavesdroping of a rootkit, virus, ...
As mentioned in #92

(or is there a secondary signature mecanism I've missed ?)
without such mecanism, SSL/TLS built-ins is the only thing we can rely on to ensure that the binaries have not been altered during transport / tempered with.

@skgsergio

GitHub is SSL only which means that they redirect each request made on http to it's https counterpart.

Didn't know that GitHub uses now HTTPS for all by default. There was a time they only did HTTPS for logged users.

Beside, if you trust your network operator to completly cover this, then you haven't underdstood the concept of WEB, AS, routing, country, borders, politics, spying & industrial spying, ...

I work in a cryptology / cryptography laboratory so I know "a little" about that and still consider using HTTPS for cloning the RPi Firmw. is useless even for me.

(Many people accepts invalid HTTPS certificates so it's easy to do a MitM anyway...)

Well, we are talking about a repo that holds firwmare for a server which means very low level binaries. Any bad guy able to MitM, would enjoy easy eavesdroping of a rootkit, virus, ...

I think I can live with that risk... Although it's possible to inject a malicious kernel module I'm sure there is little chance of this happening.
Anyway there is no sense on discussing this due GitHub now only uses HTTPS.

@GrmpCerber

Well I agree that the risk is low but the cost of adding TLS is low too. That's why I switch TLS on as frequently as I can. (I wouldn't like it if the risk was proved)

(Many people accepts invalid HTTPS certificates so it's easy to do a MitM anyway...)

Yes, unfortunatly ... but now you can use tools such as HSTS : several major browsers interpret this instruction and forbids the user to accept invalid certificate for tagged sites

@popcornmix
Collaborator

Can you squash the changes to the README and force push.

@GrmpCerber

Sorry popcornmix, I'm not as fluent in git as you :)
I gave a look at rebase / squash but since I've commited rpi-update between my two README commit, I can't find a way to rebuild a nice commit history.

I'll give it a second look during the weekend

@popcornmix
Collaborator

On your branch type
git rebase -i HEAD~3
you should see the three commits in an editor. You can choose to edit, reorder or squash them.
Squash 02e3544 into 4287efb. Check git log looks okay, and
git push -f`

This pull request will automatically update.

GrmpCerber added some commits May 17, 2013
@GrmpCerber GrmpCerber Changed install procedure since rpi-update is now available as a pack…
…age.

See #93
Hexxeh#93

Restoring old installation technique following comments of skgsergio in
addition of the new `apt` based installation

mending indentation
777e314
@GrmpCerber GrmpCerber Correction for #92 c34d0dd
@GrmpCerber

Nice :)
Thanks popcornmix, I've learned something today ! (yet it took me almost half an hour to figure out the reorder thing :p)

@popcornmix popcornmix merged commit b6b9bae into Hexxeh:master May 19, 2013
@GrmpCerber GrmpCerber deleted the GrmpCerber:PackagedInstallAndTlsEverywhere branch May 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment