Unzipping the Boost distro
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute. I'm thinking we should stop distributing raw .zip files without an extractor... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
I used WinZip without problem - I didn't notice how long it took so it must have been a short time. Robert Ramey David Abrahams wrote:
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute.
I'm thinking we should stop distributing raw .zip files without an extractor...
David Abrahams wrote:
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute.
It the built-in XP extractor is unbearably slow, my guess is that developers will have found an alternate solution long before downloading the boost distribution. (Maybe during the unzipping XP was doing something helpful like searching for updates to Windows Media Player every five seconds.) Jonathan
Jonathan Turkanis wrote:
David Abrahams wrote:
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute.
It the built-in XP extractor is unbearably slow
It generally isn't. I've never noticed a problem before. But I heard of it once -- when I brought a zipped boost distro with me to a course I was teaching, it took each developer an hour to unzip it.
my guess is that developers will have found an alternate solution long before downloading the boost distribution.
Guess again ;-)
(Maybe during the unzipping XP was doing something helpful like searching for updates to Windows Media Player every five seconds.)
Doubtful. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Jonathan Turkanis wrote:
David Abrahams wrote:
It the built-in XP extractor is unbearably slow
Should be 'If', but I guess you figured out what I was trying to say
It generally isn't. I've never noticed a problem before. But I heard of it once -- when I brought a zipped boost distro with me to a course I was teaching, it took each developer an hour to unzip it.
Ouch.
my guess is that developers will have found an alternate solution long before downloading the boost distribution.
Guess again ;-)
Okay. I guess if this is a problem which might occur for the first time while unzipping boost, it makes sense to provide a self-extracting archive in addition to the three formats already provided. Jonathan
Jonathan Turkanis wrote:
I guess if this is a problem which might occur for the first time while unzipping boost, it makes sense to provide a self-extracting archive in addition to the three formats already provided.
Very good idea.. Just tried creating a self-extract archive with 7-zip, my preferred zip tool which I recommend to all.. And it created one in about 5 minutes with maximum compression with a resulting 8.9MB archive (smaller than all the other archives we provide). It decompresses in less than a minute, on my slow 1.2Ghz machine. I guess I should add this to the set of available downloads :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Jonathan Turkanis wrote:
...it makes sense to provide a self-extracting archive in addition to the three formats already provided.
Very good idea.. Just tried creating a self-extract archive with 7-zip, my preferred zip tool which I recommend to all.. And it created one in about 5 minutes with maximum compression with a resulting 8.9MB archive (smaller than all the other archives we provide). It decompresses in less than a minute, on my slow 1.2Ghz machine.
I guess I should add this to the set of available downloads :-)
And I just did.. After updating my 7-zip we now have an 8.46MB archive which decompresses in under a minute :-) (I think the limiting factor is hard drive speed) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
At 06:15 PM 12/13/2004, Rene Rivera wrote:
Rene Rivera wrote:
Jonathan Turkanis wrote:
...it makes sense to provide a self-extracting archive in addition to the three formats already provided.
Very good idea.. Just tried creating a self-extract archive with 7-zip,
my preferred zip tool which I recommend to all.. And it created one in about 5 minutes with maximum compression with a resulting 8.9MB archive
(smaller than all the other archives we provide). It decompresses in less than a minute, on my slow 1.2Ghz machine.
I guess I should add this to the set of available downloads :-)
And I just did.. After updating my 7-zip we now have an 8.46MB archive which decompresses in under a minute :-) (I think the limiting factor is hard drive speed)
Thanks, Rene! --Beman
At 10:16 AM 12/13/2004, David Abrahams wrote:
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute.
I'm thinking we should stop distributing raw .zip files without an extractor...
The XP unzip tool is a disaster speed wise. That has nothing to do with Boost; the problem affects any .zip file of more than trivial size. I'm not sure we need to do anything about it, other than perhaps add a mention on the download page. --Beman
David Abrahams wrote:
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute.
I'm thinking we should stop distributing raw .zip files without an extractor...
David Abrahams wrote:
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute.
I'm thinking we should stop distributing raw .zip files without an extractor...
IIRC I had the same problem, but was able to get it to unzip in a reasonable amount of time by using the right-click context-menu from the Windows Explorer Folder View. I don't have my XP based laptop here at the office. I'll see if I can reproduce the method this eveneing. Jeff
On 12/13/04 10:16 AM, "David Abrahams" <dave@boost-consulting.com> wrote:
I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute.
Maybe a bug report needs to go to MS.
I'm thinking we should stop distributing raw .zip files without an extractor...
Which would make it useless to anyone not on a Windows machine. (And don¹t say "use the *.tar.gz or *.tar.bz2 versions," because I could've countered with the same advice.) I dislike the idea of executable-wrapped archives in general. You only have a creator's word that the file isn't actually a Trojan and/or infected with a virus. (Even a trustworthy creator may get overridden by a cracker's altered archives.) Those archives are useless to people on other platforms, unless the extractor's developer took extra time to add code to decode the first platform's executable formats. This is late, and it seems that you guys agreed to an extractor-included version as an addition instead of a replacement. Maybe we should add a list of MD-5, or other checksum, values for each of our archives. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
I dislike the idea of executable-wrapped archives in general. You only have a creator's word that the file isn't actually a Trojan and/or infected with a virus. (Even a trustworthy creator may get overridden by a cracker's altered archives.)
That is true regardless of type of archive. The source archives are just as susceptible to tampering as the executable ones. And such tampering has occurred in other open source distributed material.
This is late, and it seems that you guys agreed to an extractor-included version as an addition instead of a replacement. Maybe we should add a list of MD-5, or other checksum, values for each of our archives.
Checksums provide only a thin veil of assurance. There is no security improvement as the checksum is susceptible to the same tampering. If you really want secure assurance you would need some form of trusted public key signature on the archives. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Daryle Walker wrote:
I dislike the idea of executable-wrapped archives in general. You only have a creator's word that the file isn't actually a Trojan and/or infected with a virus. (Even a trustworthy creator may get overridden by a cracker's altered archives.)
That is true regardless of type of archive. The source archives are just as susceptible to tampering as the executable ones. And such tampering has occurred in other open source distributed material.
I believe what Daryle is getting at here is the fact that on one particular platform it is common practice to execute a downloaded file itself (or an attachment, or...) instead of using a trusted local executable to inspect the content of a downloaded file. It's certainly always a good idea to validate the integrity of an unknown file, however it's much less dangerous if such files are passive data instead of executable code that could harm the whole machine. Regards, Stefan
Stefan Seefeld wrote:
Rene Rivera wrote:
Daryle Walker wrote:
I dislike the idea of executable-wrapped archives in general. You only have a creator's word that the file isn't actually a Trojan and/or infected with a virus. (Even a trustworthy creator may get overridden by a cracker's altered archives.)
That is true regardless of type of archive. The source archives are just as susceptible to tampering as the executable ones. And such tampering has occurred in other open source distributed material.
I believe what Daryle is getting at here is the fact that on one particular platform it is common practice to execute a downloaded file itself (or an attachment, or...) instead of using a trusted local executable to inspect the content of a downloaded file. It's certainly always a good idea to validate the integrity of an unknown file, however it's much less dangerous if such files are passive data instead of executable code that could harm the whole machine.
OK, got that.. But my point was that there is no such thing as passive data when you distribute programs, or fragments thereof. Whether they are in source form or directly executable you are equally susceptible to tampering. Therefore the only way to produce a secure product is to secure the entire process, something I think none of us are willing to embark on for Boost ;-) So it comes to two other choices: provide for an independent trustee of the archives (PK or other authorities), or individual guards against malicious content (firewalls, anti-virus programs, etc.). Hopefully all Boost users are intelligent enough to have already done the latter. And perhaps we can do something about the former. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
OK, got that.. But my point was that there is no such thing as passive data when you distribute programs, or fragments thereof.
When I download a tar.bz file there isn't *anything* anybody can do with that file. It's simply not executable. Setting the executable bit will just cause the system to throw up its hands with an error message. Providing the 'convenience' of self-executability is just a huge dis-service to all potential recipients, at least when security is an issue. And, as far as tampering goes, what's wrong with checksums ? All you are interested in is to know that the file you downloaded is identical to the one your trusted peer packaged for you. Regards, Stefan
Stefan Seefeld wrote:
Rene Rivera wrote:
OK, got that.. But my point was that there is no such thing as passive data when you distribute programs, or fragments thereof.
When I download a tar.bz file there isn't *anything* anybody can do with that file. It's simply not executable. Setting the executable bit will just cause the system to throw up its hands with an error message.
But that has nothing to do with someone tampering with the source code that is in the archive, which users compile and execute. If someone inserts malicious code in the archive it will be at least as dangerous as the executable you use extract the archive, even if it is part of a self extracting archive.
Providing the 'convenience' of self-executability is just a huge dis-service to all potential recipients, at least when security is an issue.
And what I said is that if security is an issue no amount of fudging of the "integrity" of the archives gets around the, *currently*, inherently insecure process of producing and posting the archives.
And, as far as tampering goes, what's wrong with checksums ?
If you don't secure the checksums themselves, they are equally susceptible to tampering. i.e. the attacker can produce "correct" checksums for the compromised archives.
All you are interested in is to know that the file you downloaded is identical to the one your trusted peer packaged for you.
That requires that you provide cryptographically verifiable confirmation that the content has not changed. Like a verified tamper proof crypto signature procedure, easier said than done. You have to consider the security of the originating device (computer+human+software), the destination device, and all the devices in between (the SF servers, routers, etc). For more detail on the what can and can't be done read some of Scheiner's articles: http://www.schneier.com/ - For example this essay: http://www.schneier.com/essay-037.html Why Cryptography Is Harder Than It Looks -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
At Monday 2004-12-20 19:56, you wrote:
Stefan Seefeld wrote:
Rene Rivera wrote:
Daryle Walker wrote:
I dislike the idea of executable-wrapped archives in general. You only have a creator's word that the file isn't actually a Trojan and/or infected with a virus. (Even a trustworthy creator may get overridden by a cracker's altered archives.)
That is true regardless of type of archive. The source archives are just as susceptible to tampering as the executable ones. And such tampering has occurred in other open source distributed material. I believe what Daryle is getting at here is the fact that on one particular platform it is common practice to execute a downloaded file itself (or an attachment, or...) instead of using a trusted local executable to inspect the content of a downloaded file. It's certainly always a good idea to validate the integrity of an unknown file, however it's much less dangerous if such files are passive data instead of executable code that could harm the whole machine.
OK, got that.. But my point was that there is no such thing as passive data when you distribute programs, or fragments thereof. Whether they are in source form or directly executable you are equally susceptible to tampering. Therefore the only way to produce a secure product is to secure the entire process, something I think none of us are willing to embark on for Boost ;-) So it comes to two other choices: provide for an independent trustee
I think it would be trivial to add "checksumming" (md5 or better) for each source file as part of the regression processing. If these were published independently, you could be rather sure your stuff hadn't been tampered).
of the archives (PK or other authorities), or individual guards against malicious content (firewalls, anti-virus programs, etc.). Hopefully all Boost users are intelligent enough to have already done the latter. And perhaps we can do something about the former.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On 12/20/04 9:01 PM, "Rene Rivera" <grafik.list@redshift-software.com> wrote:
Daryle Walker wrote:
I dislike the idea of executable-wrapped archives in general. You only have a creator's word that the file isn't actually a Trojan and/or infected with a virus. (Even a trustworthy creator may get overridden by a cracker's altered archives.)
That is true regardless of type of archive. The source archives are just as susceptible to tampering as the executable ones. And such tampering has occurred in other open source distributed material. [TRUNCATE the rest as checksumming doesn't affect whether or not embedded extraction code is a good idea.]
But standard archive formats are not executable in and of themselves. Expanding a passive archive won't initiate any attack vectors for mal-ware. An archive with executable code attached adds a potential attack vector with dubious benefit. (The real problem is that the OP's un-zipper sucked performance-wise, but an embedded one may be just as bad. The fix is to use a better extractor.) Whether or not the files _within_ the archive have been perverted is a separate matter from what I originally talked about. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
But standard archive formats are not executable in and of themselves.
As I mentioned elsewhere, that is irrelevant.
Expanding a passive archive won't initiate any attack vectors for mal-ware.
Yes it can. And has been historically, re: tiff, png, jpeg, shown that bugs in non-embeded expanders can be exploited even with "passive" archives.
An archive with executable code attached adds a potential attack vector with dubious benefit.
Do you consider the following a dubious benefit: * A guaranteed extraction performance. * A guaranteed construction performance. * A 200% compression improvement. (ZIP = 17.7M, EXE = 8.5M) And hence a download improvement.
(The real problem is that the OP's un-zipper sucked performance-wise, but an embedded one may be just as bad. The fix is to use a better extractor.)
Yes. And a self-extractor is one way to provide such a better extractor.
Whether or not the files _within_ the archive have been perverted is a separate matter from what I originally talked about.
But the executable part of a self-extractor is "within" the archive. It is attacked the same way you would the rest of the archive content. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
On Tue, Dec 21, 2004 at 12:20:35AM -0600, Rene Rivera wrote:
Daryle Walker wrote:
But standard archive formats are not executable in and of themselves.
As I mentioned elsewhere, that is irrelevant.
I suspect it's a lot easier to replace a self-extracting exe with a malicious exe than it is to create a zip file that exploits a flaw in an unzip application, which relies on the flaw being present and easily exploitable.
Expanding a passive archive won't initiate any attack vectors for mal-ware.
Yes it can. And has been historically, re: tiff, png, jpeg, shown that bugs in non-embeded expanders can be exploited even with "passive" archives.
You can try to minimise problems from malicious tiffs, jpegs, etc. by applying patches and updates from your distributor. You can't do anything to reduce the chance of a malicious exe harming you, except not run it.
Whether or not the files _within_ the archive have been perverted is a separate matter from what I originally talked about.
But the executable part of a self-extractor is "within" the archive. It is attacked the same way you would the rest of the archive content.
The difference from perverted sources within the archive is that users _can_ inspect the source if they want to. They can't inspect what an exe will do before they run it. Whether the malicious code is within or without the archive is irrelevant, whether the malicious code is already compiled and executable is what matters, surely? jon -- "The value of a technical conversation is inversely proportional to how well the participants are dressed." - Larry McVoy
----- Original Message ----- From: "Jonathan Wakely" <cow@compsoc.man.ac.uk>
On Tue, Dec 21, 2004 at 12:20:35AM -0600, Rene Rivera wrote:
Daryle Walker wrote:
But standard archive formats are not executable in and of themselves.
As I mentioned elsewhere, that is irrelevant.
I suspect it's a lot easier to replace a self-extracting exe with a malicious exe than it is to create a zip file that exploits a flaw in an unzip application, which relies on the flaw being present and easily exploitable.
But it is not much harder to replace the code for e.g. the constructor of shared_ptr to include code that starts a virus, collects personal information or anything like that.
Whether or not the files _within_ the archive have been perverted is a separate matter from what I originally talked about.
But the executable part of a self-extractor is "within" the archive. It is attacked the same way you would the rest of the archive content.
The difference from perverted sources within the archive is that users _can_ inspect the source if they want to. They can't inspect what an exe will do before they run it. Whether the malicious code is within or without the archive is irrelevant, whether the malicious code is already compiled and executable is what matters, surely?
Any user that inspects all boost source code before compiling and running it still has the option to download a .zip archive. But how many users check the source code anyway? If you trust the source code, you could as well trust the executable. If you can replace the executable with malicious software, you can also replace the archive with almost an identical boost library, with some hidden malicious code inside it. If the boost community is worried about archives getting replaced with archives containing malicious code, it is probably more effective to check every night that the files available for download did not change. Publishing hashes does not add security. If you're able to change the archive, you are also able to change the published hash value. You could of course publish the hash value at several different servers, and require that users check all hashes, but who would take that much pain? You are not going to be able to defend against an attacker that has write access to the archives. Only daily or even hourly checking that the available archives are still correct can minimize the threat of corrupted archives. best regards, Richard Peters
On 12/21/04 1:20 AM, "Rene Rivera" <grafik.list@redshift-software.com> wrote:
Daryle Walker wrote:
But standard archive formats are not executable in and of themselves.
As I mentioned elsewhere, that is irrelevant.
Yes it is. I'm talking about extraction programs that the user has versus one that the creator/cracker provides.
Expanding a passive archive won't initiate any attack vectors for mal-ware.
Yes it can. And has been historically, re: tiff, png, jpeg, shown that bugs in non-embeded expanders can be exploited even with "passive" archives.
I knew about this counter-argument. But the creator/cracker doesn't have knowledge of what manipulating program you have, so s/he has no guarantee that the bug will execute. With a self-extracting archive, s/he generally does have a guarantee that her code will run.
An archive with executable code attached adds a potential attack vector with dubious benefit.
Do you consider the following a dubious benefit:
* A guaranteed extraction performance. * A guaranteed construction performance. * A 200% compression improvement. (ZIP = 17.7M, EXE = 8.5M) And hence a download improvement.
Making an archive self-extracting means adding bytes, for the executable code. How can the archive get smaller? The only way that I know of was if the compression routine from the first archive sucked. Adding self-extracting code makes no difference about that, the superior archiving code can be provided by separate programs which the user can obtain. (The exception is if the self-extracting code takes the dangerous step of being a part of the actual compressed data, and not just tacked onto the end of the archive proper.)
(The real problem is that the OP's un-zipper sucked performance-wise, but an embedded one may be just as bad. The fix is to use a better extractor.)
Yes. And a self-extractor is one way to provide such a better extractor.
But not the only way. So the question is if it's worth the risk.
Whether or not the files _within_ the archive have been perverted is a separate matter from what I originally talked about.
But the executable part of a self-extractor is "within" the archive. It is attacked the same way you would the rest of the archive content.
Your talking about all the data at all conceivable times of any use. I'm talking about only the self-extraction code only at expansion time, leaving the security of the expansion of the archive proper afterwards as a separate problem. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
On 12/21/04 1:20 AM, "Rene Rivera" wrote:
Daryle Walker wrote:
Expanding a passive archive won't initiate any attack vectors for mal-ware.
Yes it can. And has been historically, re: tiff, png, jpeg, shown that bugs in non-embeded expanders can be exploited even with "passive" archives.
I knew about this counter-argument. But the creator/cracker doesn't have knowledge of what manipulating program you have, so s/he has no guarantee that the bug will execute. With a self-extracting archive, s/he generally does have a guarantee that her code will run.
They do have knowledge of what you have. They have statistical knowledge, and that is all they need to mount an attack. For example, if you are building a ZIP for attack you know that more than 95% of the people will be running Windows. You also know that part of those, say 50%, will run WinXP or better. And part of that, say 80%, will use the built in Microsoft ZIP extractor. So for the current 8162, as of today, Boost ZIP downloads you can reasonably expect to hit 3100 systems. Case in point... "Other vulnerabilities reported Tuesday lie in how Windows XP and Windows Server 2003 handle compressed files in the .zip format. Users enticed to a malicious Web site with specially crafted ZIP files, or fed the same by e-mail, could see their PCs grabbed by attackers." http://informationweek.com/story/showArticle.jhtml?articleID=49901123 InformationWeek > Microsoft Security > Microsoft Patches 21 Bugs In Windows, Exchange, Office > October 13, 2004
An archive with executable code attached adds a potential attack vector with dubious benefit.
Do you consider the following a dubious benefit:
* A guaranteed extraction performance. * A guaranteed construction performance. * A 200% compression improvement. (ZIP = 17.7M, EXE = 8.5M) And hence a download improvement.
Making an archive self-extracting means adding bytes, for the executable code. How can the archive get smaller? The only way that I know of was if the compression routine from the first archive sucked.
Bingo :-) The algorithms that make up the ZIP format are some of the worst in the LZ class. The program that I used to generate that EXE uses a much better, in compression and decompression, algo called LZMA. See http://www.7-zip.org - And can create "solid" archives, ala tar/(gz|bzip). And the decompression algo code is very small, compared to the overall size of the archive.
Adding self-extracting code makes no difference about that, the superior archiving code can be provided by separate programs which the user can obtain.
True.. I could have created a *.7z archive and made people install the extractor. But the original point was to provide the same convenience as the in-built ZIP in WinXP. That is to have a fast extracting archive available on machines that do not, or can't, have another extractor installed. (re: Dave's original complaint) The gains in archive size where incidental.
(The real problem is that the OP's un-zipper sucked performance-wise, but an embedded one may be just as bad. The fix is to use a better extractor.)
Yes. And a self-extractor is one way to provide such a better extractor.
But not the only way.
Correct, which is why I said "one way" :-) But it is the currently only known way that satisfies Dave's original wish/request/complaint.
So the question is if it's worth the risk.
The argument that I've been explaining, and which Richard Peters summarized very well, is that it's a risk equivalent to the posting of the ZIP archive we already have. And a risk 1117 people have already taken ;-)
Whether or not the files _within_ the archive have been perverted is a separate matter from what I originally talked about.
But the executable part of a self-extractor is "within" the archive. It is attacked the same way you would the rest of the archive content.
Your talking about all the data at all conceivable times of any use. I'm talking about only the self-extraction code only at expansion time, leaving the security of the expansion of the archive proper afterwards as a separate problem.
Not considering the entire process is the _biggest mistake_ people make when attempting to secure something. Attackers will attack the weak points, so if you have one weak point your entire process is insecure. For examples, horror stories, and more see Greg Schneier's web site and research, like the "Applied Cryptography" book. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Another argument that I thought of this morning: suppose we do not publish a self-extracting executable. What is going to stop an attacker from not uploading his own self-extracting look-alike? If he can change existing archives, he probably can add other archives as well. And against what adversary do you wish to defend yourself? If I download an executable, I run it, and nothing happens, I start investigating, and will probably figure out what has happened in a short period of time. This is one kind of attacker: one that just replaces (or adds) his own executable to the list of available archives. But consider this other attacker: one that takes the original .zip archive, adds his executable in tools/build/jam_src, and adds a command to build.bat to execute his own executable. I download it, unpack it, compile bjam and compile the rest. I do not notice anything strange, so I'm not on the alert. This attacker has a far higher chance of doing far more damage than the first attacker, but the last attacker didn't even need executable archives. I'm far more afraid of this last attacker, but I just can't defend myself from this covert attack. If the boost distribution was the only executable I would ever have to download and execute from the internet, then you have a point. But then again, in that case I would choose for the .zip archive. But reality is that I download many more executables. If I look at my download directory, I see ethereal, fineprint, ad-aware, winpcap, winamp, googletoolbar, and so on, all downloaded and executed in the last few months. It's a risk I'm willing to take, and it's a risk most people are willing to take. If you really do not want to take that risk, there's always the .zip archive, which you extract and of course, before you use it in your project, you check every source file for hidden backdoors or malicious software. From: "Rene Rivera"
Not considering the entire process is the _biggest mistake_ people make when attempting to secure something. Attackers will attack the weak points, so if you have one weak point your entire process is insecure. For examples, horror stories, and more see Greg Schneier's web site and research, like the "Applied Cryptography" book.
Bruce Schneier has written excellent pieces about real-life security. While "Applied Cryptography" is a great book for cryptographers, an even better choice would be one of his other books, "Secrets and Lies" and "Beyond Fear". In these books he explains in plain human english the every-day concepts of security, and how real-life security is so easily broken. On his website, www.schneier.com, he publishes his monthly newsletter Crypto-gram, in which he, like in his books, discusses recent news about security things (this can be real security products, but more often the US government policies are discussed) in a manner that is understandable without any knowledge of cryptology. For everyone who is security-consious, these articles are really a must-read. best regards, Richard Peters
participants (2)
-
Beman Dawes -
Daryle Walker -
David Abrahams -
Jeff Flinn -
Jonathan Turkanis -
Jonathan Wakely -
Rene Rivera -
Richard Peters -
Robert Ramey -
Stefan Seefeld -
Victor A. Wagner Jr.