search for: nastygram

...imiting the build to X86, there is a > smaller probability of a build failure with a toolset which is not > checked on a day-by-day basis, as msvc is. MSVC *is* continuously checked; see http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9. Anyone who breaks the MSVC build will get a nastygram from buildbot. -Eli

Eli Friedman <eli.friedman at gmail.com> writes: > MSVC *is* continuously checked; see > http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9. Anyone > who breaks the MSVC build will get a nastygram from buildbot. This is new news for me. If the developer who broke the msvc build receives a nastygram, would he urged to fix it when he has no msvc compiler and probably no Windows machine either? The "don't break the build" mantra applies to *nix only. No LLVM developer will be ba...

...9, 2009 at 3:35 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> MSVC *is* continuously checked; see >> http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9.  Anyone >> who breaks the MSVC build will get a nastygram from buildbot. > > This is new news for me. > > If the developer who broke the msvc build receives a nastygram, would he > urged to fix it when he has no msvc compiler and probably no Windows > machine either? The "don't break the build" mantra applies to *nix > o...

Am 09.08.09 23:36, schrieb Eli Friedman: > > MSVC *is* continuously checked; see > http://google1.osuosl.org:8011/builders/clang-i686-xp-msvc9. Anyone > who breaks the MSVC build will get a nastygram from buildbot. > Please note that the MSVC buildbot only builds the X86 target at the moment. I don't know why though.

...count or the root account is compromised. Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door. And it's happened before*. Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). I'm shocked I can't find something that does this with a basic google search. Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). Has...

Eli Friedman <eli.friedman at gmail.com> writes: > On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> I think most LLVM users on Windows are interested on X86 only. This >> saves a lot of time on the build process and creates smaller >> executables. Anyways, it they want all targets, it is simply a matter of >> passing

...) manually compile in IPSEC (not done in GENERIC or the release), 2) have an entry for ipcomp in your security associations. You may also want to check what you negotiate with trusted peers if you use IKE. 3) an attacker needs to know the endpoint addresses (and the CID) to send you a nastygram. 4) if you require an outer ESP between peers, it's a matter of how much you trust your peer. FreeBSD will not panic, you may however be able to "store" packets in the network stack for IPv4 and see the netstat -s -p ipcomp packets in counter go up quickly. IPv6 has a net.inet6...

On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> Also, now msvc support multiple target. So it's better to set it as >> ${LLVM_ALL_TARGETS} >> It's can working, why not set it to:. > > I think most LLVM users on Windows are interested on X86 only. This > saves a lot of time on the build process and creates smaller >

...l-source-2.2.19-6.2.1.i386.rpm from redhat I then treid to apply the patches: cat ../ext3-0.0.6b/linux-2.2.19pre14.kdb.diff | patch -sp1 cat ../ext3-0.0.6b/linux-2.2.19pre14.ext3.diff | patch -sp1 But got prompted for which file to patch and not knowing what to do I returned through them and got nastygrams about hunks being ingnored. This I can see since I did not tell it what to do. Can I apply these patched to the redhat source and if so what do I need to do? I just subscribed to this list and have not recieved a message yet so I hope you guys are out there. This output is a little different si...

...account is compromised. > > Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door.? And it's happened before*. > > Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). > > I'm shocked I can't find something that does this with a basic google search.? Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys)...