GIT_SSL_NO_VERIFY=true is an insecure default

[febs]

Why is cloning done with that option in the dockerfile?

ignoring SSL verification is a bad practice, you are for sure aware that an attacker could inject his/her code in place of the official sdrangel one, and let me build whatever he/she wants me to, if I don't verify the source of the repository I'm cloning from.

I guess you chose to do so for those cases where the {repository} is not the official github one, but then I believe the user should give trust to the git server certificate (or its ca) or explicitly choose_ to ignore the SSL failure.

Ignoring SSL verification by default, is definitely not recommended (especially when most users are going to use github.com anyways).

Thank you for your attention!

[f4exb]

This is a security concern out of the manuals not out of practice. What kind of breach are you trying to prevent here? Somebody tweaking the build from your system? Shouldn't it make more sense to make access to your build system more difficult for an attacker in the first place. Once the intruder is there then he/she can forge any Dockerfile anyway.

Clearly this does not make sense to me and does not deserve any action on my part.

[febs]

No, you didn't understand that right - or I didn't describe it well.

Let's assume that my build system is 100% attack-proof, and only I can access it. I run ./build.sh to get the vanilla image. The script wants to clone the source code from github.com and it does NOT verifies the source because of that flag.

In this very moment an attacker (sharing my physical network and by using ARP spoofing, but that can happen anywhere between me and github where I have absolutely no control; a internet service provider operator could trivially do that), could use a man in the middle attack to let me clone his repository rather than yours and I won't even notice it with that "flag".

This is actually the very basics of SSL (and thus HTTPS) security Sir.

Denying that is like discrediting the fact that all the web is (finally) moving to SSL and the web browser are (finally) using strong messages to discourage users to browse cleartext sites rather than permitting to click "ok go on" as they used to do a decade ago.

Choosing to ignore SSL by default is really a bad practice. Not all situations can allow a proper SSL setup, but then there must be a clear awareness by the user. Chosing to do SSL connections without verification breaks the SSL and does not pose any awareness to anyone.

I hope that's clearer now.

[f4exb]

Okay

[febs]

Thank you for your understanding, Sir.

After all, if you would not want to use a browser that does not check SSL to browse your bank site, why would you compile a software on your system, without that check (even if into a dockerized image)?

[f4exb]

I am not checking my bank account with SDRangel.

[febs]

You might, if what you build is not sdrangel but something else because you don't check the code you download.

Il giorno mer 26 ago 2020 alle ore 17:16 Edouard Griffiths < notifications@github.com> ha scritto:

I am not checking my bank account with SDRangel.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/f4exb/sdrangel-docker/issues/14#issuecomment-680944507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAETSEZO2DQZTWB6MOFK45DSCURLDANCNFSM4NM6NZTA .

-- Fabio

[f4exb]

Let's face it: for absolute security your network should not be connected to Internet in any way which makes this discussion pointless since access to Github or any other public repo is then made impossible. In the event you need some external resources they should be put in a private repo inside your isolated network with extremely careful replication using all possible tools or visual inspection to detect any malicious code. I think a piece of malicious code can very well make its way to the official certificated Github repo.