best way to ensure './' is at beginning of sys.path?

[Chris Angelico]

On Mon, Feb 6, 2017 at 1:19 PM, Steve D'Aprano
<steve+python at pearwood.info> wrote:
> On Mon, 6 Feb 2017 09:26 am, Chris Angelico wrote:
>
>> On Mon, Feb 6, 2017 at 9:07 AM, Steve D'Aprano
>> <steve+python at pearwood.info> wrote:
>>> As far as "regular backups", well, you're just not thinking deviously
>>> enough. If I were to write a ransomware application, running as the
>>> regular user, I would have the application encrypt files and emails just
>>> a few at a time, over a period of many weeks, gradually increasing the
>>> rate. By the time the victim has realised that their files have been
>>> encrypted, their backups have been compromised too: you can restore from
>>> backup, but you'll be restoring the encrypted version.
>>>
>>
>> If you commit everything to git
>
> git is not a synonym for "version control system".

I know. And someone could use Mercurial for the same purpose. I happen
to use git.

> You're going to put the emails you send into subversion before hitting send?
>
> What about the emails you receive?

Those are all handled on my server, not my own system. I'm actually
toying with putting those in git too, but at the moment, they're not.

And it'd never be subversion. I don't like subversion. It would be git.

> How about graphic and video designers? Just how well does hg cope with
> gigabytes of video data?

I've no idea, but I know that git can handle large amounts of data.
(There are a couple of extensions that make it easier.)

> *Maybe* applications like LibreOffice could be integrated with VCS, and
> that's actually not a bad idea, but for binary files that can get costly.
> Yes, hard drives are big, but if every time you hit Ctrl-S on a 400K
> spreadsheet you end up with another copy, plus overhead, that adds up
> quickly. Not everyone is going to either want, or be able to, keep multiple
> years worth of versioning data for all their content.

So don't use spreadsheets like that. If you're paranoid, *use plain text*.

I invoice my clients in plain text, and keep them in a git repo.

> (Let's not forget that Android phones and tablets are Linux too. Some people
> use Android as their main, or only, computing platform, with relatively
> restricted resources. Not everyone has 10TB of storage on their computer.)

I don't have a phone so I can't speak to its practicality.

>> and keep an eye on your diffs before you push,
>
> Every time you push a file, you're going to check whether every other file
> in your home directory has changed?

In that repository, yes. It's all done by the one command "git
status". The only files you could corrupt without me noticing are
those mentioned in .gitignore, which are either safe to lose (eg
intermediate files, created from tracked files) or very private and
small (eg my SSH private key - if someone corrupts that, I'll have to
generate a new one, but that happens if I lose my HD too).

>> the encryption would have to be _extremely_ sneaky. For
>> starters, it'd have to infect the 'git' command, so it has all the
>> same protections other people have been talking about.
>
> Not at all. All it would need to do is mess with the git database behind the
> scenes: when encrypting file X, delete all the diffs for X. Or simply
> corrupt the repository.

Uhh, you can't just delete all the diffs. That would change the commit
hash, and git would instantly notice.

Corrupting the repo might work, but it's highly likely to break the
'git push', which I would notice.

Also, I frequently eyeball 'gitk', so you would also have to hide it
from the diffs.

> If people did this, then there would be an arms race with others writing
> software to repair the damage to the repository, or changing their backup
> regimen to include backing up the repo history (if you're not already doing
> this) but then the same problem applies: if the repo is corrupted subtly
> enough, you may not notice until the backups are all corrupted too.

Actually, it's more going to be that corruption will have to be done
such that the SHA1 doesn't change *and* I don't spot it in the diff
(if you just add a bunch of random junk to the file so its SHA1 is the
same, I'm going to notice that).

> And of course, sometimes backups don't work...
>
> https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
>
>
>> It'd need to
>> somehow make the SHA1s match, or else simultaneously infect my system
>> and whereever I'm pushing to (which is sometimes GitHub and sometimes
>> my own server). So the first thing is to infect everyone's git so it
>> accepts the corrupted files as well as the correct ones... AND it has
>> to still be able to show diffs, or I'd notice it very quickly.
>
> How will you notice? You edit file "funny_video_about_a_cat.mp4" and push it
> into VCS. Meanwhile the malware encrypts "birthday_party_invites.doc",
> pushes it into the repo *as you*, and once the encrypted version is there,
> deletes all the past history for that file.

I would see that, because that file shouldn't have changed. And you
can't just delete the past history. It doesn't work that way.

> Because the encrypted version is now in the repo, you won't notice the file
> has changed until you try to open it in the word processor. Which you might
> not do until your next birthday, a year from now.

Right. But I wouldn't have that as a word processor file - it would be
a text file (reStructuredText or Markdown), so I would see the diff.

> Unless you make a habit of studying *in detail* the complete history of
> everything in the repo, *and* have a good enough memory to say "wait a
> minute, I didn't edit that file on November 16th, something is suspicious",
> a sufficiently sneaky and clever ransomware app will be able to subvert
> your VCS.

I don't study the *entire* history - just the bit since I last pushed
(usually less than a day), and eyeball the most recent commit or two
as a means of regaining context. Sufficiently-sneaky ransomware could
rewrite all the history, but it would have to (a) rewrite it such that
the SHA1s are the same, and (b) corrupt a minimum of two, possibly
three, versions simultaneously, because otherwise there'll be a
version that I can easily and quickly pull down.

> Of course, so long as there are millions of Windows users with no backups,
> there are easier fish to fry. But consider that not all malware is targeted
> at arbitrary people. "Advanced Persistent Threats" may be targeted at you
> specifically, for any value of "you".

Right. I used to be the most obscure target in the world (running
OS/2), but now that I'm on Linux, I'm on a major platform, and thus
targetable.

>> Is that still frightening complacency?
>
> Talk is cheap -- do you actually push everything into VCS and regularly
> check it for corruption and unexpected changes, or are you just suggesting
> this is what you will do if and when such sneaky malware starts targeting
> Linux users?

Yes, I do - not because I'm paranoid about this kind of malicious
attack, but because I want to know about other configuration changes.
If I do some Twitch streaming and OBS changes its configuration, even
if I don't consciously commit that, I'll notice it the next time I do
anything in my "general private stuff" repository - such as invoicing
a client, which happens about every weekday. So that'll show up in
'git status', and I'll know to go look at it.

Naive corruption that just changes the file and deletes the original
would be utterly useless for all text files (because it's blatantly
obvious and would result in an immediate checkout), and mostly useless
for binary files (even if I commit the corrupted file, I can always
checkout the old version later). So it would have to be a git-aware
corruption.

> Personally I'm not losing any sleep over this -- but that's because I am
> complacent, secure in the knowledge that I'm not important enough to have
> the sort of enemies that will build an APT against me, and that ordinary
> ransomware criminals have got easier targets to go after.
>
> :-)

This is true. This is very true. But the cool thing is that malice can
be blocked by the same techniques that block accidental mistakes, and
it's worth deploying those techniques because mistakes WILL HAPPEN.
Frequently. My habit of keeping everything in git has saved me from at
least one hard drive melt-down (I lost about half a day of work in
rebuilding the computer and reauthenticating myself with my new keys),
and it probably saves me from stupid fat-fingering at least a few
times a month. If ever I get hit by a malicious attack, it would have
to be a very sneaky one to be more dangerous than my own stupidity :-)

ChrisA