Slashdot Mirror
Critical Git Security Vulnerability Announced
An anonymous reader writes Github has announced a security vulnerability and has encouraged users to update their Git clients as soon as possible. The blog post reads in part: "A critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related software that interacts with Git repositories, including GitHub for Windows and GitHub for Mac. Because this is a client-side only vulnerability, github.com and GitHub Enterprise are not directly affected. The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem....Updated versions of GitHub for Windows and GitHub for Mac are available for immediate download, and both contain the security fix on the Desktop application itself and on the bundled version of the Git command-line client."
This is only an issue if you pull untrusted content, and are on a case insensitive file system. This is not typical git usage, but its a good thing to know about.
If you do thing like pull from a repo, and run the build scrips without reading them first, you already had worse security problems, and there is nothing worse about this. It seems like the main fear would be (case insensitive) servers doing automated pulls and such getting compromised by hostile repo.
Servers that pull from lots of git repos could spread such attacks virus style, but I really don't think many such networks of auto git pulling servers exist. More likely is a specific targeted attack against some servers, but I expect most run on case sensitive file systems.
I'm puzzled that Github is stated as the main actor here. They are just
broadcasting the official announcement from the git mailing list. They are not
involved in the initial discovery, subsequent investigations or fixes. How come
this post end up giving them most of the credit? Have people already
forgot that Git and Github are different entities?
Yeah, what's next? Case-insensitive email addresses and domain names?
Remember, the whole reason files have names and not sequences of random hex is for human legibility. For most applications, case sensitivity does not increase legibility.
How can I believe you when you tell me what I don't want to hear?
This isn't a specific git problem. It's a windows problem.
I have source trees that I can't check out of an SVN server on windows because either the files get overwritten by different case filenames being aliased onto the same file or the file tree being to deep for windows.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Technically, NTFS isn't case insensitive.
The APIs used take care of making it behave that way from an application perspective. NTFS is case preserving by default, and case sensitive in the data structures. Pretty much every API written to access NTFS drives would explode if confronted by a NTFS file system that had been used in a case sensitive manner, but thats another story.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.
However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...
Karma be damned...
One could alternately argue: do you feel it's a good thing for something.dat and Something.dat to reference two different files? Because that would never confuse users, right? Shall we next talk about forward slash versus backslash in path separators, and how one is obviously much more logical and intuitive than the other? Or maybe we should get into line endings, or perhaps how there really shouldn't be any distinction between text and binary files? UTF-8 vs UTF-16?
Newsflash: different operating systems have different conventions and different quirks. I'm going to take a wild-ass guess and predict that you believe the choices of your preferred OS are obviously the correct choices.
Irony: Agile development has too much intertia to be abandoned now.
Actually, Microsoft themselves has an API for accessing NTFS drives in a case-sensitive manner, and I'm not talking about the native NT API or even the FILE_FLAG_POSIX_SEMANTICS Win32 file API flag. All versions of NT from 3.1 (the first) to 6.2 (Win8; it was removed from 8.1) have support for a POSIX operating environment - basically a full Unix-like OS running atop the NT kernel - and for proper Unix-like-ness it is case sensitive.
Mind you, Win32 programs do tend to get confused by it all. For example, CMD's "dir" command will list both "test.txt" and "TEST.TXT" in the same directory, and even correctly note if they have different sizes or datestamps. However, the "type" command (print file contents) on *either* name (or some other-cased version of the name) will instead print the contents of one of the files - doesn't matter what you type, the OS will pick - and it will print it twice (once for each copy of the file with that name).
I've been using the Interix (name of the Unix-like operating environment that runs in the NT POSIX subsystem, as reported by the uname command) build of git for years now. I should probably stop - the repo my package manager used has died, and I haven't bothered to set up a different package manager yet so my packages are outdated - but I am, humorously enough, not vulnerable to this particular attack even with that outdated version.
There's no place I could be, since I've found Serenity...
This is like the big flamewar back from the days of VMS vs Unix.
As for me, I'm happy that we've moved beyond 8+3.
"First they came for the slanderers and i said nothing."
So does Windows, though you may confuse the Win32 API if you use it. NTFS is case-preserving and the native APIs are case-sensitive. Win32 functions can use FILE_FLAG_POSIX_SEMANTICS to require case-sensitivity, and Interix (Microsoft's POSIX-on-NT environment that runs in the Subsystem for Unix Applications or SUA) does so by default. I don't know of any way to make Win32 case-sensitive by default without doing some kind of crazy hooking of the relevant APIs or installing a filter driver to enforce it.
There's no place I could be, since I've found Serenity...
Some developers use shared file systems on CIFS, whether Microsoft file server or Samba based. Some of us also inherit code that uses mixed case that maps to the same file name when made single case for legacy reasons: I can name several old UNIX programs that do not compile on CygWin without considerable revision of their source code, due to precisely this sort of issue.
For creating case-insensitive file systems.
What.
The.
Fuck.
IBM probably deserves some credit (or blame) as well, VM/CMS's filesystem may not have been case insensitive (since filenames were all upper case), but 3270 monitors had a switch that would toggle the screen display between mixed (or lower) case to all uppercase. You could still type in mixed case, but it was displayed as upper case.
Yeah, what's next? Case-insensitive email addresses and domain names?
Remember, the whole reason files have names and not sequences of random hex is for human legibility. For most applications, case sensitivity does not increase legibility.
You are conflating two things that are (or should be) separate: the file system and the UI.
The file system (paths and names) should be case sensitive. If I give the VFS a string of bits that represents a file's name (regardless of ASCII, Unicode, or EBCDIC) it should take those bits and store them as-is and give them back as-is with interpreting them.
The UI (whether the GUI or maybe the CLI shell) could then make things easier for humans by treating "p" like "P", but the file system should treat them differently.
There is a difference after all between "Polish metal" (geographic connotations) and "polish metal" (to make shiny). Or, as another example, the sentences "I helped my Uncle Jack off a horse" and "I helped my uncle jack off a horse". If you want to have your GUI/CLI treat them the same, go ahead (just set your $LC_COLLATE appropriately), but don't bake that shit into the VFS or FS.
HFS+ switched from Unicode 2.1 to 3.2 decomposition/normalization a few years back which caused issues for git:
http://marc.info/?l=git&m=120104708602274&w=3
Really: a file system should give back exactly what was put into it (both in terms of files and data).
Yes, I remember those flame wars, but to me at the time it was UNIX against the world.
But having worked for years on minis with files names consisting of 8 characters [A-Z] and 1 level 'directories', I kind of miss being forced to use short file names like DOS had. Multi-level directories are cool though.
One pet peeve of mine is people creating file names like: "this is a book of my whole life and everything i know.doc'" drives me crazy :)
Are there any advantages to case-sensitive file systems?
What?
I think there is a bit of a difference, though -- email addresses and domain names are typed by hand by the "average" (read: GUI-only) user on a day-to-day basis. That filenames were case-insensitive probably made a lot more sense back when the average user had to type at a command line -- in which case yeah, it probably was a better UX to have case-insensitivity (at least, from a casual user's perspective). In today's world of GUIs, case sensitivity might not increase legibility -- but it doesn't decrease legibility either, and is (I think?) a POSIX violation.
:)
Despite the fact that I think case-sensitivity is a Good Idea, I really like zsh's ability to tab-complete in a case-insensitive fashion
An AC above somewhere (comment: "polish != Polish") had a great comment: there's a difference between the filesystem and the UI. If a UI (file manager, shell, etc.) wants to reference two different files in a different fashion, fine. But the filesystem "should give back exactly what was put into it (both in terms of files and data)."
It's another bit of pandering to the stupid. Rather than encourage people to go into the direction of sanity, the path of least resistance is to turn the bug into a feature. Microsoft and Apple are both guilty of that. Encouraging whitespace in file names is another indicator of this.
I don't let Unix and descendants get off so lightly, either. While they have sanity w/r/t filename case and the use of slash as a path-element-separator character, they do allow allow not just blanks but also control characters as well as spaces in file names. While it is possible to make a case for such characters in names, I think possibilities for error and misuse far outweigh the advantages.
No. Two different byte strings should identify two different files (unless one or both of them are invalid byte streams). Anything else is introducing complexity into the filesystem and potential bugs and security violations, of which this it an excellent example. Sorry, but Unix has it right, and Microsoft and lots of other systems are *WRONG*.
Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.
There is a difference after all between "Polish metal" (geographic connotations) and "polish metal" (to make shiny).
Not at the beginning of a sentence.
Or, as another example, the sentences "I helped my Uncle Jack off a horse" and "I helped my uncle jack off a horse".
Or better yet, "I went to my Uncle Jack's stud farm and helped him jack off a horse". Not that there's anything wrong with that.
Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.
This article makes a pretty convincing case that we'd be better off with some restrictions on filenames. It's hard to argue the point that allowing certain characters in filenames causes more problems than it solves.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
MS chose case-aware (you can use case), but case-insensitive. In typical MS fashion, that is the absolute worst possible behavior that still somehow gets the job done. Case unaware, or case sensitive are both fine, but this stupidity cause countless problems.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Yes. There is only one possible name for addressing a file. For a case-aware, but case insensitive, you get up to 2^n variants for a name n letters long. And you _can_ have the same name with different capitalization in a directory as result of errors.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I think it's technically a misfeature - or maybe a wart. It was intentional...
.: Semper Absurda
One pet peeve of mine is people creating file names like: "this is a book of my whole life and everything i know.doc'" drives me crazy :)
You can definitely blame Microsoft for that one (default Word filename is first line of document).
.: Semper Absurda
I boot linux from a vfat formatted USB stick, you case insensitive clod.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.
Stepping back from HFS+ they've even supported case-sensitive file systems long before that since you could use UFS on OS X. Even OS 9 supported it but I don't remember if you could boot that from it.
However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...
Yep. The Adobe suite won't even open files over NFS.
Because some characters have special significance to the shell. That includes * and ?. In the bad old days of dos, you could enter an arbitrary character code by holding Alt while entering the 3 digits on the keypad. Character 255 looked exactly like a space but was not equivalent. Imagine the confusion one could cause that way.
SureItDoes.
Of course, if not for the convention of all smalls in domain names we wouldn't get to snicker at expertsexchange.com
Yes. There is only one possible name for addressing a file. For a case-aware, but case insensitive, you get up to 2^n variants for a name n letters long. And you _can_ have the same name with different capitalization in a directory as result of errors.
Funny, since Linux does everything it can to break a canonical name model with symlinks. In fact, you could mimic a case-insensitive system with 2^n symlinks like /foo/bar/COnFiG -> /foo/bar/config. And the captialization is the cause of errors in mixed environments:
1) Create file on Windows called "Foobar.txt".
2) Copy it to your Linux machine.
3) Rename it to "FooBar.txt"
4) Do lots of work on the text
5) Copy it to your Linux machine
6) Copy the Linux directory back to Windows.
There's now a 50-50 chance that your work just got overwritten by old crap from step 2). Of course you might argue that Windows is the problem here since it wouldn't happen on two Linux systems, but then it wouldn't happen on two Windows systems either. They just don't play nice with each other.
Live today, because you never know what tomorrow brings
That was my favorite way of hiding things.
do you feel it's a good thing for something.dat and Something.dat to reference two different files? Because that would never confuse users, right?
Case sensitivity is locale-dependent. If the user is bilingual, the file system then has to guess which language the user is thinking in when opening files.
Finally! A year of moderation! Ready for 2019?
They work for bilingual users. Case-insensitive file systems are limited to languages with identical case folding. The rest of us are screwed.
Finally! A year of moderation! Ready for 2019?
A symlink different from the file it points to. You are probably confusing it with a hardlink. At least get the basics right before you post something like this.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I dont know if its a bug, it makes navigation more simpler.
Any evidence to back up the claim?
When 10+ years ago I was moving from Linux to Windows, the case-sensitve file system was one of the major risk factors.
But even in the beginnng, I have encountered precisely zero problems with it. And I'm the type who works mostly on the terminal and should be directly impacted by the case-sensitive file names.
The thing is, these days, nobody types the filenames manually: it is either click in GUI with the mouse or filename completion on the command line. And even if the filenames needs to be typed manually, literally everybody universally uses the lower case. (That even on Windows. And I have helped in past correct the case handling in several Windows applications so that they create files with consistent upper/lower case names. Because users were complaining that it is inconvenient and kind of fugly that sometimes output filenames are upper case, sometimes lower case.)
As such, I consider case-insensitive file names to be a redundant feature.
All hope abandon ye who enter here.
Despite the fact that I think case-sensitivity is a Good Idea
Why? I've never heard a single good argument in favour. With programming, you often want case sensitivity to distinguish between a public Name and a private name, but the same need isn't there with files, and case-sensitivity is just more likely to lead to mistakes. I say POSIX should be changed to prefer case-insensitive filesystems.
== Jez ==
Do you miss Firefox? Try Pale Moon.
There's no separate api. All requests for file objects go through the NT Object Manager which then passes it to the NTFS file system driver. There's actually a flag (OBJ_CASE_INSENSITIVE) that you pass to the kernel if you don't want it to consider case. The Win32 api always pass this flag. You can support case sensitivity in your application by not passing this flag.
I've never been able to make much sense of Adobe's stance in this, but as far as I can tell Adobe thinks that case-sensitive file systems are useless and if they wait long enough they will go away.
I vaguely remember that one version of Photoshop failed on case-sensitive volumes, and there was a patch circulating that fixed about 9 filenames scattered throughout the code, and solved the problem. Rather than applying this patch, Adobe chose to block installation on case-sensitive volumes in modern versions.
I don't find the case convincing at all.
Enjoyed skimming through it, especially the point about character encoding and the value of utf-8. Many arguments for name restrictions are because it would make shell commands and scripts easier to write correctly. That suggests to me the bigger issue is the shell.
As the computer language Forth shows, there does not have to be an obvious line between a programming language and a command line. It's unfortunate our systems generally have multiple languages with different conventions. What might be better is a good language with levels of parsing, sort of like the difference between JSON and JavaScript, or HTML/CSS and JavaScript, where some levels are not intended to have executable code and the system knows that. Anyway, just a seed of an idea.
Just to try to grow it a bit, imagine if (shudder, as I prefer Smalltalk syntax) we used JavaScript as a "shell" syntax. When you wanted to delete a file, you might enter:
$ File.remove(["force"], "file name with spaces or not");
instead of:
$ rm -f file\ name\ with\ spaces\ or\ not
Actually, I prefer the JavaScript version. :-)
Because JavaScript is so flexible, you could do in some JavaScript shell profile:
var rm = File.remove;
var rmf = rm.bind(["force"]);
Then, with assumed semicolons you could write:
$ rmf("file name with spaces or not")
That seems much clearer to me than the conventional shell script notation.
Commands could return JavaScript objects for results, displayed as JSON. So:
$ File.list()
{"test1.js", "test2.js"}
$ File.list(["long"])
{".": ["drwxr-xr-x+", "pdfernhout", "staff ", 2822, "2014-12-03Z08:14"], /*", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"]}
"..": ["drwxr-xr-x+", "pdfernhout", "staff ", 2822, "2014-12-03Z08:14"],
"test1.js", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"],
"test2.js", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"],
"-rf", ["drwxr-xr-x+", "pdfernhout", "staff ", "1234", "2014-12-03Z08:14"],
"metacharacter & ||||| weirdness!!!! | rm -rf
$ rm("metacharacter & ||||| weirdness!!!! | rm -rf /*")
$ rm("-rf")
I'm not sure if there would be other stiff like pipes that might trip you up, especially with JavaScript's syntax and single-tasking assumptions. Probably the results of these functions might have to be some form of Deferreds or something like that?
As a first cut at pipes, assuming the result of a previous operation as a JavaScript object is passed as a final argument to the next operation:
$ File.list().then(File.grep.bind("test*")).then(File.write.bind("out.txt"))
Or with appropriate aliases via var and an assumption that "then" does a bind for arguments:
$ ls().then(grep, "test*").then(write, "out.txt")
Seems much easier to me to really understand this. It's a tradeoff of course. You might be typing a few more characters sometimes than for something like Bash, but whenever you tried to do something complex, it might be more understandable than a mess of metacharacters. And then file names (in ut8) without restrictions on metacharacters would not be such a big issue. These functions could even have a case-insensitive option.
with a IMHO human-friendly syntax like one derived from Smalltalk, where you used spaces to separate messages instead of a dot ("."), you would have:
$ (File ls) then: [File grep: "test*"] then:
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
so what?
The file system is independent of the shell. My shell probably uses different special characters than yours too - ^ means something in mine for example.
Adding complexity into the file system because people are idiots is silly. If you really need to you can wrap an idiot layer on top the file system after all.
the case-sensitve file system was one of the major risk factors.
Don't worry, as XKCD shows, this is not an issue.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
All the complexity you need to add is:
if (ch <= '\x1f') {
goto FAIL;
}
How hard is that?
I have explained how all this works, with all the gory detail, in a blog post at http://www.nicklowe.org/2012/0...
Why stop there?
They should also add a spell checker and auto-correct to the file system driver just to make sure people haven't made any mistakes.
How does that stop you using * and ? in a file name. How does that stop you using "Character 255" in a filename?
It does of course stop you using utf8 filenames.
A quick glance at that article seems more like a compelling case for teaching people how to write shell scripts properly.
If you read the article, you'll find that writing shell scripts to handle filenames containing every possible character "properly" is so difficult that virtually everyone gets it wrong. When something's been around for close to 40 years and still nobody can get it right, maybe it's time to admit that it's the tool that's broken.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
So you need to have some way to enter those characters when specifying a file name. Escap chars can handle some of that, but it really is best to not take chances where it can cause problems. For example, imagine a file named 'bobby; rm -rf /'
Filesystems can be used in myriad ways. What if I want to cache a bunch of files, with the filename being some sort of hash? In this case, it would make sense for a79t5qr.png to be a different file than A79t5qR.png .
Personally, I prefer knowing that the filename I type is the filename the file gets. If I want to call something "finaldraft.txt" and "FINALdraft.txt," that should be up to me.
That's no way to talk about Linus, even if he did leave his door unlocked!
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
How about because English isn't completely case-insensitive. Pronounce this: POLISH. You can't know you're doing it properly. Now, pronounce Polish and polish. No problem, right? Similarly, Danish is an adjective referring to a nationality, while danish is noun denoting a pastry. "bismarck" (lower-case) cannot be a nineteenth-century German politician, a WWII battleship, or a city in North Dakota. Christians worship God while Romans worshipped gods.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
As I understand it, in English a case-sensitive filesystem would have "fish" and "FISH" be the same, but that would be an error in a Turkish one. What's lower-case of "STRASSE"? Should the filename with the "ss" be the same as the one with the letter that looks like a beta? I used to be a fan of case-insensitivity, but I've come down on the side of preferring the system that actually works everywhere.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
So has COBOL.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Right, because it's a daily problem I have that I want to put files called Polish and polish in the same directory. And I can't think of any way to differentiate them other than capitals.
What a dumb argument.
By the way, what about when you can't distinguish them by capitals? What if I want a file about my new table in the same directory as my table of figures? What do I do then?
== Jez ==
Do you miss Firefox? Try Pale Moon.
Just because .NET APIs call down to Win32 APIs, which call down to NT APIs, doesn't mean that they aren't all different APIs. Same for the POSIX APIs (which, like Win32, chain to native NT APIs). The POSIX ones always specify OBJ_CASE_INSENSITIVE, the Win32 ones do if you specify FILE_FLAG_POSIX_SEMANTICS, and I don't even know if .NET supports enforcing case-sensitivity... but they are still separate APIs. Nobody in their right mind writes user-mode software against the native NT API unless they absolutely have to, and not only because it's prone to occasionally changing in non-backward-compatible ways.
There's no place I could be, since I've found Serenity...
Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.
This article makes a pretty convincing case that we'd be better off with some restrictions on filenames. It's hard to argue the point that allowing certain characters in filenames causes more problems than it solves.
Sorry - if the tools that we have for managing the labels that humans wish to place on their objects are lacking, we should fix the tools, not the labels. For example, I've named my dog "Crankshaft" - does that confuse mechanics? The only thing we humans have is the ability to manipulate symbols. I'd prefer to have no restrictions on the labels that I use, since they simply refer to objects.
The native NT API's don't actually change that much in breaking manner. Many ISVs, especially security software, rely on calling into the native API for stuff that isn't possible with Win32. Only recently has Microsoft gotten better at exposing much of that functionality. For instance if you had a handle to a thread and wanted to get the thread id, even though it's a very basic operation there was no way to do that before Windows Vista. Now there's GetThreadId.
Sorry - if the tools that we have for managing the labels that humans wish to place on their objects are lacking, we should fix the tools, not the labels. For example, I've named my dog "Crankshaft" - does that confuse mechanics? The only thing we humans have is the ability to manipulate symbols. I'd prefer to have no restrictions on the labels that I use, since they simply refer to objects.
It's a common problem in the programming field to make a virtue out of overgeneralization, even when it conflicts with other virtues, such as ease of use or security. What actual benefit do you get from allowing the inclusion of control characters in filenames? How does that benefit compare with the amount of pain and extra effort involved in dealing with those filenames?
The other thing is that "fixing the tools" is a complete non-starter. You're talking about "fixing" a large subset -- possibly even a majority -- of programs on Unix systems, in a way that will be incompatible with existing tools. The elegance of putting some minor restrictions on filenames into the filesystem is that it works with virtually all existing user-level software, with no changes to that software required.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
/ is one of the two characters I said were fine to not allow, due to implementation simplicity. So there's no need to imagine such a file name.
But I have no problem with ";" in file names (or "|", or "&", etc). I don't interpret file names as shell commands since I put the commands in the text of the shell script files not in the file names.
It doesn't matter what YOU interpret as a file name vs command, it matters what the shell considers a filename vs a command. Nit pick the example all you like, but if ; is a valid char, tears will result. I don't see where bobby;rm -rf * would be that much better. It's begging to be exploited.
Case sensitivity is a good idea. The problem is that trying to do "case insensitive" matching depends on the locale. If you send your files to someone else, whether or not they are the "same" depends on your locale if you're serious. For Turkish users, 'i' and dotted 'I' are the same if you're considering them as case-sensitive; for many other languages and users, the dots create DIFFERENT characters. And if you're trying to make this "easy" it doesn't go far enough; Latin "a" usually looks the same as Cyrillic "". So please don't say "users can't tell the difference" - they ALREADY can't tell the difference visually, and naive solutions do not begin to address it. At least you can visually see the difference betweeen "Picture" and "picture", and in any case, users typically just click on the item and move on.
I think it would be a GOOD idea to require that Unix-like filenames be legal UTF-8 sequences (since you then know how to display them), and then reject filenames that are not UTF-8. But that's much less intrusive than filename mangling.
That said, it's too late to fix Windows, so if you're going to run on Windows you have to deal with the problem as it is.
- David A. Wheeler (see my Secure Programming HOWTO)