- cypherpunks - lists.cpunks.org

Re: [tor-talk] [liberationtech] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
by grarpamp 17 Nov '13

17 Nov '13

> I don't think that's possible at the moment. There are no > deterministically built operating systems yet. This is rather sad. I think FreeBSD has a project somewhere trying to move that way. Hopefully all of the unix-likes are at least aware of the concept, if not having an actual project for it. Also, none of the BSD's have any built-in integrity in their repositories, they just insist their infrastructure and committers are infallible among other escuses. (Excepting DragonFly which uses git, don't know if they sign it though. Monotone seems better at that sort of embedded pki thing.).

1 0

Re: [Cryptography][Law] Jeremy Hammond Banned from using Cryptography
by John Young 16 Nov '13

16 Nov '13

That should have been Bernie-S, not -X. And Mitnick now runs a rather profitable security service and lecture series. About Jim Bell (he can speak for himself but I know best how to smell and tell a rat): The IRS secret agent leading Jim's chase, Agent Gordon, lurked on cypherpunks for a long time, gathering names and addresses to subpoena for Jim's grand jury probe and (first) trial. Several of us were subpoenad along with cpunks records from some (John Gilmore one of those). Some, like me, were summoned both for the grand jury and the trial held in Tacoma, WA. (Sidebar: youngster Declan McCullagh covered that and I urged him to report seditiously enough to be sent to jail to build his rep -- he politely refused to cellmate Jim.) Short story (full account in the archive) is that not many supported Jim all the way when the shit came down, indeed, brazenly ridiculed his adventure, presumably to cover their ass from Agent Gordon and co-lurkers always on duty hereabouts. Who secretly ratted Jim at the grand jury remains unknown but their behavior and sweat odor has been profiled by god and they will not be given authentic bitcoins, only fakes with their undercover UID embedded like Lamo. At 06:13 PM 11/16/2013, you wrote: >On Sat, Nov 16, 2013 at 8:36 AM, John Young <jya(a)pipeline.com> wrote: > > ... > > At a HOPE panel on informants, several hackers disclosed > > those pressures to rat, some succumbed and were let off, > > Emmanuel Goldstein admitted it, some refused and were > > jailed, Bernie-X, Kevin Mitnick. All agreed it is far worse to > > go through than you think. Goldstein estimated 25% of hackers > > are rats. > >Jim Bell's exhortations to deny all pleas a hard sell considering that >one in four rolls over completely under pressure. :/ > > > > > Barrett Brown is on the hot seat right now, being offering deals > > to rat, as customary, with three (!) trials postponed to maintain > > pressure. Shit, even his mom was used as a fed provocation to > > misbehave then as a persuasion club as were Sabu's nephew > > and niece. > >it would be interesting to see a survey of the carrots and sticks used >by federal prosecutors. > > > > > Anybody with a high profile is targeted, so beware publicity > > hounds crowing of derrying-do and urgings by high profilers > > who may or may not be in the grips of the feds, and if not, > > will soon be due to their publicity narcosis, and then used > > as clubs or head to jail for obstruction and recidivism or > > some other nut-squeezing -- even in jail they are offered > > deals to rat and sentence reduced. > >good thing JYA stays under the radar! Sorry to say Radar mag did a smear of us. > > In or out jail the pressure to rat continues, as with Adrian > > Lamo. Ex-cons never know if an overture is an LE sting or a > > an honest request for advice, so they rat to be safe -- recall > > they are obliged -- forever -- to report overtures, just like > > ex-spies remain under the gun to rat for life. If you haven't > > been there don't imagine you know what it's like. > >what do you mean by "obliged -- forever -- to report overtures"? i >would be very interested to know if there are clauses compelling >disclosure in these agreements for unrelated activities. is this >"soft" pressure, or legally binding? Notice upon release from prison that ex-cons are expected to be on call. Panoptic assured. Moreso for ex-spies. > > Don't imagine this list and others like it, chats, OTRs, TOR, > > are not being spied for easy targets. > >this opportunistic spying even has a code name: EPICFAIL Also Open Source.

1 0

[Cryptography][Law] Jeremy Hammond Banned from using Cryptography
by Privarchy Mee 16 Nov '13

16 Nov '13

Can any of you, most of whom I do not doubt are far more knowledgeable about cryptography and how it's conceptualised within the legal sphere, offer some insight regarding this? https://twitter.com/CyMadD0x/status/401443518612512769 The claim is that Judge Loretta A. Preska, who sentenced Jeremy Hammond today, said that for the three years (post-release) that he was to spend under supervision, he will not be able to use encryption for communication or storage purposes(!) which is practically a legal edict to go and build a cabin by Walden Pond. How can this be considered anything but cruel and unusual?

10 12

[tor-talk] Tor 0.2.4.18-rc is out
by Roger Dingledine 16 Nov '13

16 Nov '13

Tor 0.2.4.18-rc is the fourth release candidate for the Tor 0.2.4.x series. It takes a variety of fixes from the 0.2.5.x branch to improve stability, performance, and better handling of edge cases. https://www.torproject.org/dist/ Changes in version 0.2.4.18-rc - 2013-11-16 o Major features: - Re-enable TLS 1.1 and 1.2 when built with OpenSSL 1.0.1e or later. Resolves ticket 6055. (OpenSSL before 1.0.1 didn't have TLS 1.1 or 1.2, and OpenSSL from 1.0.1 through 1.0.1d had bugs that prevented renegotiation from working with TLS 1.1 or 1.2, so we had disabled them to solve bug 6033.) o Major bugfixes: - No longer stop reading or writing on cpuworker connections when our rate limiting buckets go empty. Now we should handle circuit handshake requests more promptly. Resolves bug 9731. - If we are unable to save a microdescriptor to the journal, do not drop it from memory and then reattempt downloading it. Fixes bug 9645; bugfix on 0.2.2.6-alpha. - Stop trying to bootstrap all our directory information from only our first guard. Discovered while fixing bug 9946; bugfix on 0.2.4.8-alpha. - The new channel code sometimes lost track of in-progress circuits, causing long-running clients to stop building new circuits. The fix is to always call circuit_n_chan_done(chan, 0) from channel_closed(). Fixes bug 9776; bugfix on 0.2.4.17-rc. o Minor bugfixes (on 0.2.4.x): - Correctly log long IPv6 exit policies, instead of truncating them or reporting an error. Fixes bug 9596; bugfix on 0.2.4.7-alpha. - Our default TLS ecdhe groups were backwards: we meant to be using P224 for relays (for performance win) and P256 for bridges (since it is more common in the wild). Instead we had it backwards. After reconsideration, we decided that the default should be P256 on all hosts, since its security is probably better, and since P224 is reportedly used quite little in the wild. Found by "skruffy" on IRC. Fix for bug 9780; bugfix on 0.2.4.8-alpha. - Free directory authority certificate download statuses on exit rather than leaking them. Fixes bug 9644; bugfix on 0.2.4.13-alpha. o Minor bugfixes (on 0.2.3.x and earlier): - If the guard we choose first doesn't answer, we would try the second guard, but once we connected to the second guard we would abandon it and retry the first one, slowing down bootstrapping. The fix is to treat all our initially chosen guards as acceptable to use. Fixes bug 9946; bugfix on 0.1.1.11-alpha. - Fix an assertion failure that would occur when disabling the ORPort setting on a running Tor process while accounting was enabled. Fixes bug 6979; bugfix on 0.2.2.18-alpha. - When examining the list of network interfaces to find our address, do not consider non-running or disabled network interfaces. Fixes bug 9904; bugfix on 0.2.3.11-alpha. Patch from "hantwister". - Avoid an off-by-one error when checking buffer boundaries when formatting the exit status of a pluggable transport helper. This is probably not an exploitable bug, but better safe than sorry. Fixes bug 9928; bugfix on 0.2.3.18-rc. Bug found by Pedro Ribeiro. o Minor features (protecting client timestamps): - Clients no longer send timestamps in their NETINFO cells. These were not used for anything, and they provided one small way for clients to be distinguished from each other as they moved from network to network or behind NAT. Implements part of proposal 222. - Clients now round timestamps in INTRODUCE cells down to the nearest 10 minutes. If a new Support022HiddenServices option is set to 0, or if it's set to "auto" and the feature is disabled in the consensus, the timestamp is sent as 0 instead. Implements part of proposal 222. - Stop sending timestamps in AUTHENTICATE cells. This is not such a big deal from a security point of view, but it achieves no actual good purpose, and isn't needed. Implements part of proposal 222. - Reduce down accuracy of timestamps in hidden service descriptors. Implements part of proposal 222. o Minor features (other): - Improve the circuit queue out-of-memory handler. Previously, when we ran low on memory, we'd close whichever circuits had the most queued cells. Now, we close those that have the *oldest* queued cells, on the theory that those are most responsible for us running low on memory. Based on analysis from a forthcoming paper by Jansen, Tschorsch, Johnson, and Scheuermann. Fixes bug 9093. - Generate bootstrapping status update events correctly when fetching microdescriptors. Fixes bug 9927. - Update to the October 2 2013 Maxmind GeoLite Country database. o Documentation fixes: - Clarify the usage and risks of setting the ContactInfo torrc line for your relay or bridge. Resolves ticket 9854. - Add anchors to the manpage so we can link to the html version of the documentation for specific options. Resolves ticket 9866. - Replace remaining references to DirServer in man page and log entries. Resolves ticket 10124. -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Re: [Cryptography][Law] Jeremy Hammond Banned from using Cryptography
by John Young 16 Nov '13

16 Nov '13

Still, the USA's description of how its Cooperating Witness (presumably Hector Sabu Monsegur) allegedly induced Hammond to ply his fine mind and technical skills indicates that ban on the use of encryption is the least hazard facing hackers and confrontational comsec wizards: http://cryptome.org/2013/11/hammond-060.pdf Self-serving insiders of the comsec industry, black, white or gray, continue to be the Achilles heel of comsec. Government use of these trusted allies reminds that it is not only nations who fuck their friends. Now, this is not news, but also reminds that protestations of injustice, outrage and anger, is all too often a conventional cover for betrayal by cooperating witnesses. Unfortunately, the same goes for eager participants in payback, fault correction, workarounds, vengeance, product upgrades to defeat the bastards. These exact means and methods were allegedly used by Sabu to ensnare and imprison a batch of confederates. An ancient practice effectively used on Julian Assange: followers can be lethal. Encryption offers squat protection from this kind of legal, political and social engineering whose history is much older and more effective than top coding, math, engineering, ethics and brave challenges to authority. Usually, offer of an irresistable plea deal, job contract, witness protection, PR outpouring, turns a valiant outsider into a handsomely rewarded insider. Mudge one of hundreds, perhaps thousands, who got the warning message. Then what to avoid the looming scythes the various Sabus (he is surely not alone) have provided law enforcement to gradually take down the opposition, not all at once but in the Snowden-Greenwald manner, to slowly dribble prosecutions for maximum effect, promising "much, much more to come?"

1 0

re: passwords! (p7)
by brian carroll 16 Nov '13

16 Nov '13

// two other techniques not yet mentioned... consider the previous example once again: [pass]-[wo]-[r]-[ds] ---> [mo]-[sp]-[ssap]-[J] there could be multiple transformations (a->b->c) that could involve switching the sequence of the set, and other such ~operations, whether to the entire password in aggregate (as string) or inside the separate 'bit' sets, each potentially having overlapped or different changes due to symmetry with alphanumerics (hiox), usually the reference is to vertical, horizontal mirroring and rotation of 180 degrees, though this could also involve 90/270 degrees, such that a pass could filter the entire string for 90 degrees, as in the example below, or in other instance, only set 1, etc. [mo]-[sp]-[ssap]-[J] ---> [3o]-[иp]-[ииap]-[J] in this example, the letters 's' when rotated 90 degrees turn into the russian lowercase 'и' via substitution. likewise the letter 'm' turned into a '3' via its partial rotation. another rule for bit set transformation could involve the contraction and expansion of what is inside the set or the string en total... such that in the original example, the duplicates letters in a given set are dropped into a single letter... though this could then double the other letters within the set... [ssap] ---> [sap] ---> [saapp] therefore, a starting password string could in a given instance change from nine to ten characters... [mospssapJ] ---> [mospsaappJ] a different take on this same technique of expansion and contraction is more deconstructive, in that that the 'intra-sign' or 'infra-sign' structure itself could be tapped into as its own layer of character abstraction. consider once again the basic example already used... [pass]-[wo]-[r]-[ds] ---> [mo]-[sp]-[ssap]-[J] it is possible to modify what is within each bit set in a range of ways, this transformative process equivalent in some sense to calculus, relying on geometric ordering as it relates to typography though could extend further into linguistics (phonetics, meaning, grammar, syntax) variables. the focus of consideration is what could potentially happen to meaningfully transform a bit set or bit string and then use this as a framework or basis for a ruleset for such processing take the first bit set in the transformed version: [mo] it can be broken down or opened up via its correspondence with other structuring, so for example the issue of rotation is such that 3,w,E,m are variables for rotation while o is the same: [3o|wo|Eo|mo] so in that particular range of parameter, the superposition for the original letter 'm' is more varied than for the letter 'o' in the same set further though, the structure of the sign itself (at the intra-bit set level of measurement), that of a single letter, could also be the basis for such transformative rulesets that further expand or contract 'variables' in that through their "options" or optionality, provide various structures that may or may not be used in given bit set permutations at multiple levels of the letter sign, intra-bit set, inter-bit set, and bit set string [mo] again, consider the potential letter-based structuring that could be broken apart and merged/fused together to either expand or contract the given alphabetic and likewise other alphanumeric example... [mo] ---> [rno] ---> [rn()] the letter 'm' is fragmented into a letter 'r' and letter 'n' which combine back into the letter m via proximity or adjacency, and the letter 'o' can be abstracted into paired symmetric parentheses. what this also does is take the bit set and expand it from two letters to four characters the takeaway is that the length of a password could be variable given what rules are involved, such that a base password could expand and- or contract and itself be variable across many of its attributes, existing in a potential state or superposition, that is more the parameters of a Schrödinger scenario than a pattern-match in a dictionary context for any given [password] that could be a million potential permutations consider the following example of a bit string instance, again... [mospssapJ] just making one transformation could change it from pw1 to pw2, say using a 180 degree rotation first, then a repeated letter function that drops a letter and expands others in the set (in this case string)... mospssapJ ---> wosdssedr ---> wwoossddseeddrr notice the original password ~instance expanded from 9 characters to 15 characters and has actually changed 'variables' of the password, so that even if the original password is known, (and then: outdated), without knowing the rules, it would not be easy to establish pw2 due to potentially infinite variability, whatever the hidden rulesets may be another example going further into this transformation via expansion is to breakdown the sign-structures, again exampled at the bit string level. mospssapJ ---> rn()s|oss|oJ not much is occuring in this example, it expands from 9 to 12 characters. though to make it more elaborate, lets rotate the letters 's' ninety degrees... moиpииapJ ---> rn()VI|⁰VIVI|⁰J this instance transforms the 9 character pw1 into a 15 character pw2 and also introduces special characters that could be mapped to alphanumeric structures. and this could go anywhere, to pw3...pwᴺ for example, further mirroring, symmetry, rotation, duplication, substitution... rn()VI|⁰VIVI|⁰J ---> L⁰|IVIV⁰|IV()nr ....horizontal mirroring of the string, and its further 180 rotation.... L⁰|IVIV⁰|IV()nr ---> ju()^I|ₒ^I^I|ₒ7 another pass could again recombine letters, such as substituting a letter 'b' for '|ₒ', and turning each letter within the set 180 degrees, if it can be mapped into another character structure... ju()^I|ₒ^I^I|ₒ7 ---> rn()VIpVIVIpL so the idea here is that it is possible to move from pw1 to pwᴺ and have a running password that is a transmutation of some original or seed password that is itself autonomous, changing and variable across a range of parameters; in this way, the password could have involve aspects of superposition in its bounded local interactions as its variability is encountered mospssapJ ---> rn()VIpVIVIpL in other words, pw1 and pw2 and pwᴺ could be a continual process of transformation, and this variability could fill time, and expand and contract and change characters, languages, inter and intra-sign structures, and likewise could include other variables as mentioned (temperature, other relativistic variables- moon phase, number of sunspots, UV index, etc) thus, pw1 could be 15 characters in one moment, 38 the next, and potentially even strengthened if more than five attempts at access occur, dropping gates and walls and further parameters, or spawning a false basic password as entry into the labyrinth... x⁽ xⁿ x⁾

1 0

re: passwords! (p6)
by brian carroll 16 Nov '13

16 Nov '13

additional layers of transformation could also be included that use symmetries or other calculus-like transformations. consider the previous example... [1][2][3][4] ---> [2][4][1][3] now consider if within each subset additional characteristics could be modified, such that set 2 is mirrored by vertically by the letters that obey these principles... and set 1 has its letters in reverse... and sets 3 and 4 are rotated 180 degrees [pass]-[wo]-[r]-[ds] ---> [mo]-[sp]-[ssap]-[J] and that this could also be dynamic and change, for a given instantiation of the base password as it is mediated for login, as an ever-changing password with its own variability which could change daily given, say, a range of 30 such criteria that may or may not be accessible in various combinations then rulesets would be important, what if some letters can be transformed and others cannot, are substitutions chosen or are only some characters changed, or how to deal with a character with multiple options for superposition translation this kind of exponential potential for passwords in a context where the simple model is so simple to allow easy hacking, what if systems were designed to be significantly more difficult to access and that /time/ was leveraged to limit unauthorized access and to limit, via relativism, what can be seen in a given threshold or timeframe, to potentially make it impossible for automated attacks of logins via brute-force via zombie-nets, by making the odds more the opposite of what they are today, given access, enough time and dictionaries, versus limiting the exploitable window, limiting the time frame, and use of dictionaries via increased variability that is never static, and thus each login could tend more towards 1 in a million guess, by chance, and have that be the repeated situation encountered at login, versus allowing 10 million attempts to gain illegal access it just seems common sense that perhaps it is made to be broken and that without such introducing or allowing parameters of such increased difficulty, that perhaps it is the design of the ecosystem itself versus its merit in terms of 'actual security' versus what is allowable, thus making the password issue itself that of a false perspective, as if 8-12 alphanumerics w/special characters is maxing out possibilities when instead limiting the questions to those parameters may force another approach prematurely, which could be even worse, policy-wise 😺 😶 😈

1 0

re: passwords! (p5)
by brian carroll 16 Nov '13

16 Nov '13

// incompleteness of completeness, additional oddity... if considering [password] as a bit-set instead of linear string, such that [p|a|s|s|w|o|r|d] could itself be variable, per bit, ex. [pass|word|1234|bluegreen] then, if a password service used this principle, instead of requiring just 8-12 alphanumerics plus allowed special characters as the basis for /security/, instead what if it was 3-4 sets instead, themselves having special rules... [set1|set2|set3|set4] in this way, a 'rolling password' could be developed in that the sequence could be arbitrary or change, given the instance or interaction, which may or may not include changing variables (months till b-day, temperature in zipcode, etc) in other words: [password] ---> [pass][wo][r][ds] whereby, via its continual dynamic state, could exist in multiple versions by default, and then have this managed between client/server [1][2][3][4] ---> [2][4][1][3] [pass]-[wo]-[r]-[ds] ---> [wo]-[ds]-[pass]-[r] this could extend into sequences of not only alphanumerics through also icons (picked amongst many on the server, thus creating more unknowns), say choose 1 of available 20 icons, which is not included in stored password, nor its place in sequence knowable to attacker... [pass][icon13][wo][r][ds] ---> [icon13][wo][ds][pass][r] thus a changing string made up of subsets rearranged that may even have non-stored variables [#], icons or other approach [3b]-[alphanum1a]-[5e]-[32^F]-[4d]-[icon]-[2c] [2c]-[3b]-[alphanum1a]-[4d]-[icon]-[67^F]-[5e] then the probabilities and computation is upped exponentially even if accessing some part of the correct code, which may not be reliably reused, seemingly the more subsets, more security from an initial attack-- thus even if one instance of passwords were found, they could be changed or even transformed into another set and detach from those lost, locking out else deactivating the previous versions. a lot could seemingly be done with this though a secure environment would be required which seems difficult to guarantee if not allow for sake of someone elses interests, known & unknown 𝓶 𝟡 𝑤

1 0

[tor-talk] USB Sticks for TAILS
by Moritz Bartl 15 Nov '13

15 Nov '13

Hi, I know there is a dedicated mailinglist for TAILS, but I figured I would reach a larger audience here, and it might be of interest to many who are not subscribed to the TAILS list. Ideally, you use TAILS from a read-only medium. CD is best, but many devices these days don't have an optical drive, and handling CDs is not as convenient as a USB stick. For quite some time, people kept recommending the TrekStor CS USB stick [ https://geizhals.de/trekstor-cs-8gb-50324-a240853.html ], one of the few sticks available in Germany with write-protection switch. Turns out they use a new firmware, and now don't support booting from it in read-only mode. The company confirmed this via email. There are roughly no alternatives, and I figured I'm not the only one looking for USB sticks with write protection switch. Via alibaba.com, a "wholesale Chinese ebay", I contacted various Chinese suppliers, and ended up ordering two samples. Even there, the selection of sticks with write protection is very limited. I ended up paying paying 60€ for the 2 samples because of shipping and Western Union fees. The sticks are not very fast, but acceptable, and boot in read-only mode. They are not as slim as I hoped for, but the supplier is friendly, production and shipping was very fast. (less than 2 weeks altogether). Logo printing is cheap ($0.15 per stick), so to try the quality I also had them print a logo on the samples. I am still undecided whether I want the final sticks to have a logo, or simply be blank to not attract too much attention. If you have a nice idea for a logo, let me know. I want to order 100 sticks in time for Chaos Communication Congress 30C3. The production cost is $4 per stick (8GB), the final price (taxes, GEMA, shipping) will likely be around $15. Pictures: http://share.pho.to/48Egt # dmesg [55679.884123] usb 2-1.2: new high-speed USB device number 5 using ehci_hcd [55680.051089] usb 2-1.2: New USB device found, idVendor=058f, idProduct=6387 [55680.051092] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [55680.051094] usb 2-1.2: Product: Mass Storage [55680.051095] usb 2-1.2: Manufacturer: Generic [55680.051096] usb 2-1.2: SerialNumber: B6BA8F3F [55680.051459] scsi9 : usb-storage 2-1.2:1.0 [55681.051827] scsi 9:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 4 [55681.053860] sd 9:0:0:0: Attached scsi generic sg1 type 0 [55681.055544] sd 9:0:0:0: [sdb] 15937536 512-byte logical blocks: (8.16 GB/7.59 GiB) [55681.056665] sd 9:0:0:0: [sdb] Write Protect is off [55681.056676] sd 9:0:0:0: [sdb] Mode Sense: 23 00 00 00 [55681.057742] sd 9:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [55681.176618] sdb: sdb1 [55681.179808] sd 9:0:0:0: [sdb] Attached SCSI removable disk # hdparm -t /dev/sdb /dev/sdb: Timing buffered disk reads: 54 MB in 3.07 seconds = 17.60 MB/sec # dd if=tails-i386-0.21.iso of=/dev/sdb bs=1M 891+1 records in 891+1 records out 934471680 bytes (934 MB) copied, 170.058 s, 5.5 MB/s -- Moritz Bartl https://www.torservers.net/ -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Re: [tor-talk] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
by Ulex Europae 15 Nov '13

15 Nov '13

At 09:04 PM 11/13/2013, grarpamp wrote: >On Tue, Nov 5, 2013 at 2:38 AM, <rwest(a)countermail.com> wrote: > > Hello, > > > > can BitMail.sf.net as a p2p email tool for encrypted Email (and > hybrid with IMAP-Email) be regarded as a reference model for > research to create a secure Email Client? as it uses both, gnupg and openssl! > > > > http://bitmail.sourceforge.net/ > > https://sourceforge.net/projects/bitmail/files/BitMail_0.6_2088RC1/ > > > > Does anyone know, if it runs over Tor? > > > > Sincerely, Robert > >So... 'Robert', who do you work for? NSA? Financial crime? >I mean, with the net moving to encrypt everything >we'd expect to see many new and unknown yet seemingly >polished tools being dropped on unsuspecting first time >users just to collect their key material. >Surely someone will have fun with your windows binaries. Hmm, lots of lists I'm not subscribed to on the To: line, bad juju on someone's part for the initial crosspost. Hopefully, those other list maintainers will see and approve my comment, even though I'm not subscribed to all those other lists: I'm replying because, Sourceforge? They fell out of vogue when they started bundling binary downloads with other executables, they deserve to die a quick death for that as users flock to safer environs. 'Robert' should upload his binaries to Github. Along with his source code. Then, if the MD5 checksum on his compiled binaries matches the MD5 checksum on the source code when it is compiled independently, he's golden. That is how that works, how it is supposed to work. Accept no substitutes. --

1 0