Mono is for.Net applications and all MS Office versions (up to and including the 2007 beta) are not.Net applications.
However, if Microsoft is planning to port any of its existing applications to Linux, then Wine could be a very important tool for them.
Wine has a different bug related to the SETABORTPROC record, but with a valid length field, not the special behaviour with a length of 1 described in the transcript.
As someone who has worked on Wine's metafile parsing code it is a massive insult. We do not use reverse engineering except as a last resort. This is not necessary in the case of metafiles since there is already good documentation available. Wine's bug was simply the lack of filtering the SETABORTPROC escape code when parsing the metafile, not the same as the bug being described here with special behaviour on the length field being 1.
The Wine bug was a different bug. The SetAbortProc record specifies a pointer to a function which will be executed at a later point, and which it would be difficult to set to arbitrary code in the WMF itself, whereas this bug appears to be creating a thread which immediately runs starts executing the instruction at the next byte in the meta file.
Do any of the standard Linux filesystems (ext2, ext3, ReiserFS) support encryption? No. There are clunky loopback kludges you can wrap over them, but they have the drawback of being clunky kludge wrappers.
So you would rather it be shoe-horned into each filesystem? How much of the metadata do you want encrypted? Most don't encrypt any metadata, so is having the size and name of the file in plain text OK?
Granted, distro support for crypto-loop could be a lot better (for example, like OS X allowing you to automatically load your encrypted home dir)
Given that this thread is about databases, how do Postgres and MySQL fare in that department? Can either of them produce PGP-signed database results? No
What?!? Why would you want that? And having to find the option to set to enable PGP signing and then to set the key is easier than just using a one line shell script?
Now let's look at other features in the Linux kernel. It has modes for running signed or encrypted ELF files, right? Wrong! Plain old plain-text should be good enough! Did someone forget support for accessing encrypted files? Guess so.
Why don't you just set up a chroot jail and make sure you are running a good Intrusion Detection System? That will be a lot easier than trying to get a standard way of storing resources (let alone certificates) in ELF files (which IMHO is a big disadvantage with ELF at the moment).
I'm trying to point out that there are some major gaps in Open Source's encryption picture
And I just I'd point out that while they are gaps in your opinion, there are other ways of solving the problems that you mention with different advantages and disadvantages.
The reason applications break is usually because they use rely on undocumented features (such as passing in bad or inconsistent values), and I know this, being a Wine developer. The root cause of this is MSDN not being specific enough and the functions not checking parameters thoroughly enough.
In fact there was even one of the WinXP developers blogging about how they bend over backwards to accomodate applications that dig 60 bytes into the stack to access a variable in a function 2 calls up.
Yes, they are a monopoly and yes, they use some questionable business practices, but don't blame the developers because even though they believe that the Microsoft way is "The One True Way", most of them are not out to sabotage applications.
P.S I am both a Windows and Linux user so I like to think I am somewhat objective when it comes to evaluating Microsoft.
I'm not sure what you think is wrong with "Linux, which hackers tend not to target", but I thought that was quite cleverly put.
From the number of viruses targeted towards Windows you can't deny this is true.
Also note that the author doesn't say why they tend not to target it, whether it is because it is harder to find ways of compromising Linux or whether it is because of its popularity, as some people claim.
Yes, it is a hardware problem but there was a workaround that added some delays so that the bug was not triggered.
There was a patch floating around for this. Try googling the archives. It may have gone into 2.6.4-mm1 so you could try that.
Slashdot Mirror
Mono is for .Net applications and all MS Office versions (up to and including the 2007 beta) are not .Net applications.
However, if Microsoft is planning to port any of its existing applications to Linux, then Wine could be a very important tool for them.
Wine has a different bug related to the SETABORTPROC record, but with a valid length field, not the special behaviour with a length of 1 described in the transcript.
As someone who has worked on Wine's metafile parsing code it is a massive insult. We do not use reverse engineering except as a last resort. This is not necessary in the case of metafiles since there is already good documentation available. Wine's bug was simply the lack of filtering the SETABORTPROC escape code when parsing the metafile, not the same as the bug being described here with special behaviour on the length field being 1.
The Wine bug was a different bug. The SetAbortProc record specifies a pointer to a function which will be executed at a later point, and which it would be difficult to set to arbitrary code in the WMF itself, whereas this bug appears to be creating a thread which immediately runs starts executing the instruction at the next byte in the meta file.
So you would rather it be shoe-horned into each filesystem? How much of the metadata do you want encrypted? Most don't encrypt any metadata, so is having the size and name of the file in plain text OK?
Granted, distro support for crypto-loop could be a lot better (for example, like OS X allowing you to automatically load your encrypted home dir)
Given that this thread is about databases, how do Postgres and MySQL fare in that department? Can either of them produce PGP-signed database results? No
What?!? Why would you want that? And having to find the option to set to enable PGP signing and then to set the key is easier than just using a one line shell script?
Now let's look at other features in the Linux kernel. It has modes for running signed or encrypted ELF files, right? Wrong! Plain old plain-text should be good enough! Did someone forget support for accessing encrypted files? Guess so.
Why don't you just set up a chroot jail and make sure you are running a good Intrusion Detection System? That will be a lot easier than trying to get a standard way of storing resources (let alone certificates) in ELF files (which IMHO is a big disadvantage with ELF at the moment).
I'm trying to point out that there are some major gaps in Open Source's encryption picture
And I just I'd point out that while they are gaps in your opinion, there are other ways of solving the problems that you mention with different advantages and disadvantages.
The reason applications break is usually because they use rely on undocumented features (such as passing in bad or inconsistent values), and I know this, being a Wine developer. The root cause of this is MSDN not being specific enough and the functions not checking parameters thoroughly enough.
In fact there was even one of the WinXP developers blogging about how they bend over backwards to accomodate applications that dig 60 bytes into the stack to access a variable in a function 2 calls up.
Yes, they are a monopoly and yes, they use some questionable business practices, but don't blame the developers because even though they believe that the Microsoft way is "The One True Way", most of them are not out to sabotage applications.
P.S I am both a Windows and Linux user so I like to think I am somewhat objective when it comes to evaluating Microsoft.
I'm not sure what you think is wrong with "Linux, which hackers tend not to target", but I thought that was quite cleverly put.
From the number of viruses targeted towards Windows you can't deny this is true.
Also note that the author doesn't say why they tend not to target it, whether it is because it is harder to find ways of compromising Linux or whether it is because of its popularity, as some people claim.
Yes, it is a hardware problem but there was a workaround that added some delays so that the bug was not triggered.
There was a patch floating around for this. Try googling the archives. It may have gone into 2.6.4-mm1 so you could try that.