There are a few filetypes that you likely don't want to add into any subversion repository, such as .pyc, .log, and .bak files. Not only do they not need to be in the repo, but you also probably don't appreciate them sullying the output of things like svn status either. Deleting all such files before each commit isn't a good option either. SVN allows you to ignore certain file patterns in the current directory (assuming it's under version control) and in all children via a command such as:
But if you then try to add another pattern, such as "*.log", the initial value of the svn:ignore property is overwritten! To overcome this, create a file containing the patterns you want to ignore, one per line. I created a .svnignore file and added it into my personal SVN, symlinked from my home directory. That way I can use it on each box I work on, on various repos as needed, since the patterns are pretty universal.
Say you have made a file called .svnignore containing:
*.pyc
*.log
Then you would run:
And the two patterns in the file would be ignored in MYDIR and all its children. If you want to add or remove a pattern later, just change the .svnignore file and re-run the same command.
You can also setup such ignores globally for a given SVN repo, but I tend to shy away from that sort of change, since I might just decide that I want some logfile checked in at one point or another. Setting the patterns per repo allows for a bit more flexibility.
One annoying note: When you add new directories to your repo, you have to run the command again. Otherwise the svn options for the new folder won't contain your ignore patterns.
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
How do we debug and profile a cloud full of processors and threads? It's a problem more will be seeing as we code big scary programs that run on even bigger scarier clouds. Logging gets you far, but sometimes finding the root cause of problem requires delving deep into a program's execution. I don't know about you, but setting up 200,000+ gdb instances doesn't sound all that appealing. Tools like STAT (Stack Trace Analysis Tool) are being developed to help with this huge task. STAT "gathers and merges stack traces from a parallel application’s processes." So STAT isn't a low level debugger, but it will help you find the needle in a million haystacks.
Abstract:
Petascale systems will present several new challenges to performance and correctness tools. Such machines may contain millions of cores, requiring that tools use scalable data structures and analysis algorithms to collect and to process application data. In addition, at such scales, each tool itself will become a large parallel application – already, debugging the full BlueGene/L (BG/L) installation at the Lawrence Livermore National Laboratory requires employing 1664 tool daemons. To reach such sizes and beyond, tools must use a scalable communication infrastructure and manage their own tool processes efficiently. Some system resources, such as the file system, may also become tool bottlenecks.
In this paper, we present challenges to petascale tool development, using the Stack Trace Analysis Tool (STAT) as a case study. STAT is a lightweight tool that gathers and merges stack traces from a parallel application to identify process equivalence classes. We use results gathered at thousands of tasks on an Infiniband cluster and results up to 208K processes on BG/L to identify current scalability issues as well as challenges that will be faced at the petascale. We then present implemented solutions to these challenges and show the resulting performance improvements. We also discuss future plans to meet the debugging demands of petascale machines.
If monthly, why not annual blog round-up? These are my top popular "Security Warrior" blog posts for 2008. Enjoy!
Also enjoy:
Monthly tops:
Annual tops:
Technorati Tags: security,blog,blogs,blogging,chuvakin,annual About me: http://www.chuvakin.org
MD5 insecure? Absolutely. SSL hacked? Sort of, but it’s not broken. CA negligence? You decide.
——————————————————————————————————————-
MD5, known for years to be vulnerable, was instrumental in allowing creation of a rogue SSL certificate last month. Although this is troublesome, it isn’t what really bothers me, even though some erroneously reported the untimely demise of SSL. The real problem seems to be MD5’s continued use by CAs to sign certificates for years after problems were identified.
The MD5 storyIn 2004, Dan Kaminsky described weaknesses in the MD5 cryptographic hash function. He predicted future attacks against it could cause problems with digital signatures. Kaminsky wrote,
The attacks discovered are indeed obscure. But completely theoretical? No. Even given what little data has been released – code implementing the attack isn’t even public yet – sufficient information has been released to piece together a rudimentary proof of concept tool that demonstrates, at minimum, that the selection of MD5 exposes new and potentially deeply undesirable functionality above and beyond what the one-way hash primitive specifies…
That being said, this paper is not a “smoking gun” indictment of MD5. I’ve taken great pains to include the caveats of each vulnerability, as it is far too easy to overestimate the risks described in this paper. It is for that reason I am not saying ”today”, or ”any day now”. The title states ”someday” for a reason. There are dots going back ten years as to the risk of MD5. Here are a few more, in the hopes that they will start to be connected.
Was there enough information available at the time to make everyone immediately jump to another hashing solution like SHA-1? Probably not. However, there should have been enough concern among certificate authorities (CAs) to protect one of the most valuable security tools on the Web–SSL.
Although the bigger CAs did begin using SHA-1 for their high-end certificates, those with fewer security guarantees (I guess to really need your lawyer read the fine print…) continued to be signed with MD5.
The 2008 “SSL” hackThe “someday” Kaminsky wrote about drew much, much closer last month with development and successful use of a proof-of-concept rogue certificate by security researchers Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger. Figure 1 is a brief description of how a malicious certificate can be substituted for the real thing during purchase and acquisition. The process is enabled largely because a majority of DNS servers are still vulnerable to redirection attacks. For a more detailed description of how this works, see the original findings paper.
Figure 1 (http://www.win.tue.nl/hashclash/rogue-ca/#sec71)
What this meansOn the surface, this “event” proves that it’s possible for an attacker to insert himself into the certificate acquisition process, resulting in wrongful authentication of visited sites. However, SSL might not be in as much danger as originally reported.
Yes, there are many CAs still using MD5 for at least some certificate signing. In fact, the rogue certificate used in this exploit emulated a VeriSign RapidSSL cert. TC TrustCenter AG, RSA, and Thawte Inc. also still use the vulnerable hash function. But there are four significant mitigating factors.
Again, these are mitigating factors. It isn’t impossible for cybercriminals to come up with an attack on their own now that conceptual understanding of approach is public knowledge. But SSL is not broken. The only thing broken is a portion of the public key infrastructure (PKI) which underlies it, and the risk is manageable.
How to mitigate riskFirst, fix DNS. Organizations which haven’t ensured their DNS services are secure should do so immediately. Second, take the plunge and filter business or home access to Web sites. (See Free Web content filtering puts safer browsing within reach for everyone and Websense.) This is far from perfect, but it helps users avoid known malicious sites as they appear on the radar. Finally, check new certificates before you purchase to see if the CA might be vulnerable and to ensure their validity. Also check SSL-secured sites you visit for the first time to ensure the cert is valid–at least for the near future.
Checking before you buy is easy. Use a reputable CA and check the signature hash function used. Checking other sites requires the right tool, like Site Check at Networking4All. To test, I entered the alternate URL for Gmail, as shown in Figure 2.
Figure 2
Since the certificate is actually for mail.google.com, this is a good way to see if Site Check accurately tags the cert as invalid. It did, as shown in Figure 3. Although this is a valuable test for common certificate issues, the MD5 exploit described in this post would likely pass. However, note that the results show the chain of trust as well as the hashing functions used. If the certificate is signed with MD5, and the certificate was obtained after the exploit was made public, you are armed with information necessary to possibly avoid the site or take additional steps to verify authenticity. If a business partner uses MD5 signed certificates, ’strongly encourage’ them to replace them with certificates signed with SHA-1.
Figure 3
The final wordSo is SSL broken? Not really. The problems with MD5 are certainly cause for concern, but the risk is not high enough to mourn the demise of secure sockets, especially if simple steps are taken to avoid high-risk behavior. Further, the problem is not with SSL itself.
Yes, MD5 is broken. Of that there is no doubt. So with years of advanced warning, were the CAs negligent for continuing to use MD5? Was the risk high enough to make the shift before release of a successful proof-of-concept hack? What do you think?
Q: Were the CAs negligent for continuing to use MD5?
Loading …
Do you believe the December proof-of-concept renders SSL insecure?
Loading …
After refreshing my rotting CSS braincells, I got a layout working properly and was quite happy. Then I tested in IE, and saw my <pre> tags being displayed incorrectly (according to my desire, not necessarily the code, which don't always align):
The above should have been two lines of text with a horizontal scroll bar. I want to say use scroll-bar for text that's too wide but expand vertically without a scroll bar: Never a vertical scroll bar, only ever a horizontal one.
I've spent a bit today scouring the web with not much help. I've randomly permuted css values for overflow, overflow-x, overflow-y, min-height, etc. Having failed that, I read everything I could find from randomly permuted search queries, one of which lead me to a depressingly long detail about IE6's expanding box problems. The page claims (and several others do, also) that IE7 fixes several box expansion problems.
I created a very small demo with minimal CSS to show the problem here: Click here to view the demo. It includes the solution I found, detailed below.
After some other random permutation, I gave up and tried wrapping the pre in a div and applying the overflow properties to the div. It worked. It's 2009 and I still have to deal with weird and obscure browser rendering inconsistencies. I came up with this: <style> .scroll-wide { height: auto; overflow-x: auto; overflow-y: hidden; max-width: 500px; } /* On firefox, pre tags have a top and bottom margin > 0, which makes your * scrolling div have a blank top line, which isn't what * we want. Fix one weirdness to find another? I didn't fully investigate. * Here's the fix: */ div pre { margin-top: 0; margin-bottom: auto; } </style> ... <div class="scroll-wide"> <pre> stuff </pre> </div>
Solving this with wrap-pre-in-a-div can be automated with jQuery and a CSS definition: // javascript $("pre").wrap("<div class='pre-wrap'></div>"); // In CSS div.pre-wrap { /* overflow/height/whatever options */ } It's still possible I was doing something wrong and that this hack isn't necessary, but I don't know. I'm just glad to have it working now.
PS: If you use Meyer's reset.css, you'll want to include pre { margin-bottom: auto; } , or IE will again clip the bottom of the pre contents with the scrollbar.
Recent comments
6 weeks 6 days ago
6 weeks 6 days ago
7 weeks 3 days ago
14 weeks 3 days ago
14 weeks 3 days ago