- cypherpunks-legacy - lists.cpunks.org

Re: [silk] Bitcoin
by Alaric Snell-Pym 06 Jul '18

06 Jul '18

On 05/17/11 02:04, Suresh Ramasubramanian wrote: > Peer to peer currency generation is something that botnets will love > to game - artificially generate cash by using other people's > computing power > > And the protocol itself might lend itself to such attacks. For > example http://www.bitcoin.org/smf/index.php?topic=823 > > Easy way to debase a currency - allow various folks to generate lots > and lots of it > > Remember, per account limits are easily worked around by scaling to n > accounts.. Ah, the limit isn't done like that. 50 bitcoin are generated about every 10 minutes, period. The more CPU time you put in, the larger a *share* of that you get, but the global rate remains the same. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[serval-project-dev] Someone has started work on something we have been planning for a while ...
by Paul Gardner-Stephen 06 Jul '18

06 Jul '18

http://code.google.com/p/twimight/ It is a twitter client for Android that features a P2P mode for when there is no internet access. Always encouraging to see this kind of thing getting underway. It is still early days for them by the look of things, but I will have a chat with them about integrating with our (not yet existent) APIs for accessing the Serval MeshMS, Meow (more on that when we can work up the documentation) and other relevant services. Paul. -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [silk] Bitcoin
by Alaric Snell-Pym 06 Jul '18

06 Jul '18

On 05/17/11 02:04, Suresh Ramasubramanian wrote: > Peer to peer currency generation is something that botnets will love > to game - artificially generate cash by using other people's > computing power > > And the protocol itself might lend itself to such attacks. For > example http://www.bitcoin.org/smf/index.php?topic=823 > > Easy way to debase a currency - allow various folks to generate lots > and lots of it > > Remember, per account limits are easily worked around by scaling to n > accounts.. Ah, the limit isn't done like that. 50 bitcoin are generated about every 10 minutes, period. The more CPU time you put in, the larger a *share* of that you get, but the global rate remains the same. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Fwd: Re: Fwd: Book Review: Peter Wayner's "Translucent Databases"
by Udhay Shankar N 06 Jul '18

06 Jul '18

<x-flowed>Bob, I forwarded your review of Wayner's book to, among others, David Brin. He sent this reply, asking me to pass it on. Seems to have touched a nerve! Udhay >Uday, thanks for sharing this. > >Could you submit the following reply? > >--------------- > >It is particularly dishonest of a so-called reviewer not only to >misinterpret and misconvey another person's position, but to abuse >quotation marks in the way Robert Hettinga has done in his review of >Translucent Databases By Peter Wayner. Openly and publicly, I defy >Hettinga to find any place where I used the word "trust" in the fashion or >meaning he attributes to me. > >In fact, my argument is diametrically opposite to the one that he portrays >as mine. For him to say that 'Brin seems to want, "trust" of state >force-monopolists... their lawyers and apparatchiks." demonstrates either >profound laziness - having never read a word I wrote - or else deliberate >calumny. In either event, I now openly hold him accountable by calling it >a damnable lie. This is not a person to be trusted or listened-to by >people who value credibility. > >Without intending-to, he laid bare one of the 'false dichotomies" that >trap even bright people into either-or - or zero-sum - kinds of >thinking. For example, across the political spectrum, a "Strong Privacy" >movement claims that liberty and personal privacy are best defended by >anonymity and encryption, or else by ornate laws restricting what people >may know. This approach may seem appealing, but there are no historical >examples of it ever having worked. > >INdeed, those mired in these two approaches seem unable to see outside the >dichotomy. Hettinga thinks that, because I am skeptical of the right >wing's passion for cowboy anonymity, that I am therefore automatically an >advocate of the left wing's prescription of "privacy through state >coercive information management'. Baloney. A plague on both houses of >people who seem obsessed with policing what other people are allowed to know. > >Strong Privacy advocates bears a severe burden of proof when they claim >that a world of secrets will protect freedom... even privacy... better >than what has worked for us so far - general openness. > >Indeed, it's a burden of proof that can sometimes be met! Certainly there >are circumstances when/where secrecy is the only recourse... in concealing >the location of shelters for battered wives, for instance, or in fiercely >defending psychiatric records. These examples stand at one end of a >sliding scale whose principal measure is the amount of harm that a piece >of information might plausibly do, if released in an unfair manner. At >the other end of the scale, new technologies seem to make it likely that >we'll just have to get used to changes in our definition of privacy. What >salad dressing you use may be as widely known as what color sweater you >wear on the street... and just as harmlessly boring. > >The important thing to remember is that anyone who claims a right to keep >something secret is also claiming a right to deny knowledge to >others. There is an inherent conflict! Some kind of criterion must be >used to adjudicate this tradeoff and most sensible people seem to agree >that this criterion should be real or plausible harm... not simply whether >or not somebody likes to keep personal data secret. > > >The modern debate over information, and who controls it, must begin with a >paradox. > >(1) Each of us understands that knowledge can be power. We want to know as >much as possible about people or groups we see as threatening... and we >want our opponents to know little about us. Each of us would prescribe >armor for "the good guys" and nakedness for our worst foes. > >(2) Criticism is the best antidote to error. Yet most people, especially >the mighty, try to avoid it. Leaders of past civilizations evaded >criticism by crushing free speech and public access to information. This >sometimes helped them stay in power... but it also generally resulted in >horrific blunders in statecraft. > >3) Ours may be the first civilization to systematically avoid this cycle, >whose roots lie in human nature. We have learned that few people are >mature enough to hold themselves accountable. But in an open society where >criticism flows, adversaries eagerly pounce on each others' errors. We do >each other the favor of reciprocal criticism (though it seldom personally >feels like a favor!) > > >Four great social innovations foster our unprecedented wealth and freedom: >science, justice, democracy & free markets. Each of these "accountability >arenas" functions best when all players get fair access to information. >But cheating is always a problem because of (1) and (2) above. It's a >paradox, all right. > >While new surveillance and data technologies pose vexing challenges, we >may be wise to pause and recall what worked for us so far. Reciprocal >accountability - a widely shared power to shine light, even on the mighty >- is the unsung marvel of our age, empowering even eccentrics and >minorities to enforce their own freedom. Shall we scrap civilization's >best tool - light - in favor of a fad of secrecy? > >Across the political spectrum, a "Strong Privacy" movement claims that >liberty and personal privacy are best defended by anonymity and >encryption, or else by ornate laws restricting what people may know. This >approach may seem appealing, but there are no historical examples of it >ever having worked. > > >Here are a few themes discussed in The Transparent Society: > >* Cameras and surveillance devices swarm our technological world, >multiplying and getting harder to spot each day. A "Moore's Law of >Cameras" shows them halving in size, doubling in acuity and movement >capability and sheer numbers, every year or so. Passing laws won't stop >them. Robert Heinlein said: "Privacy laws only make the bugs smaller... >and limit their use to some elite." > >But there may be another solution. > >* Knowledge is the ultimate drug, and forbidden knowledge is craved above >all. Credit companies, banned from holding bankruptcy records beyond 7 >years, now ship the taboo information to offshore 'data havens.' Shall we >create an underground economy in contraband information, as we have done >with drugs? Who will benefit? > >* One wing of the Strong Privacy crusade wants Euro-style privacy >commissions with a myriad laws and clerks to police what may be known by >doctors, corporations, and individuals. Dataflow controls may indeed be >needed at times! But this solution should be a last resort, not the first >place we turn. > >* Another wing of wing of Strong Privacy likes libertarian techno-fixes -- >empowering individuals with encrypted cybernetic anonymity. But scientific >and social flaws may render these panaceas no more effective than 'ghost >shirts'. Even if they can be made to work, it may just empower a new >elite - those who best know-how to use the new masks and armor. > >* Is government the chief enemy of freedom? That authority center does >merit close scrutiny... which we've been applying lately with >unprecedented ardor. Meanwhile other citizens worry about different power >groups -- aristocracies, corporations, criminal gangs, and technological >elites. Should 'suspicion of authority' apply in all directions? Can >anyone justifiably claim exemption from accountability? > >* Privacy and personal safety are better safeguarded by catching peeping >toms. Freedom thrives when we turn 'henchmen' into >whistle-blowers. Elites will always have some advantages, but we're all >better protected by knowing than by forbidding others to know. (It is far >easier to verify that you know something, than to verify that someone else >is ignorant.) > >* Why do our "accountability arenas" work so well? Science, justice, >democracy & free markets are direct products of openness... most of the >people knowing most of what's going on, most of the time. Even individual >eccentricity seems to flourish best in light. Closed societies have >always been more conformist than open ones! > > >Many of these points may seem counter-intuitive... but so is our entire >rambunctious, argumentative, tolerant, eccentric, in-your-face culture! >The Transparent Society explores underlying issues, from the technological >(cameras, databases and the science of encryption) to the startling (why >all our films preach suspicion of authority), helping foster a new >appreciation of our unique civilization. > >Defying the temptations of secrecy, we may see a culture like no other, >filled with boisterous amateurs and individuals whose hunger for >betterment will propel the next century. This will happen if we stick to a >formula that already works... most of the people knowing most of what's >going on, most of the time. > > >==================================================================== > > >"New tech is handing society tough decisions to make anew about old issues >of privacy and accountability. In opting for omni-directional openness, >David Brin takes an unorthodox position, arguing knowledgeably and with >exceptionally balanced perspective." > - Stewart Brand, Director, Global Business Network > >"As David Brin details the inevitability of ubiquitous surveillance, your >instinct, as an individual facing this one-way mirror, is to hope that he >is wrong about the facts. As you follow his argument for two-way social >transparency, you realize your only hope is that he is right." > - George B. Dyson, author, Darwin Among the Machines > >"Where, in the information age, do we draw the line between privacy and >openness? David Brin's answer is illuminated by his insistence that >criticism is as vital to eliminating our errors as the T-cells of our >immune system are to maintaining our health. . . . Brin's informed and >lucid advocacy of fresh air is very welcome." > - Arthur Kantrowitz, Professor of Engineering, Dartmouth College > >"David Brin is one of the few people thinking and writing about the social >problems we are going to face in the near future as the result of new >electronic media. The Transparent Society raises the questions we need to >ask now, before the universal surveillance infrastructure is in place. Be >prepared to have your assumptions challenged." > - Howard Rheingold, author, The Virtual Community > >"The Transparent Society reframes the debate on what our world can >become-and the choices aren't what they may seem." > - K. Eric Drexler, author, Engines of Creation > >"David Brin's nonfiction marvel, The Transparent Society, is what Lewis >Mumford or Thorstein Veblen might write, could they contemplate our >increasingly webbed world and its prospects for social change. It's what >Benjamin Franklin or Thomas Jefferson would be writing these days about >technology and democracy. Brin's book is full of imaginative, far-sighted >concern for how fluid information is going to transform our civil society. >Knowledge only occasionally leads to wisdom, but here we see some, and the >book is so wonderfully entertaining that it's bound to be widely read." > - William H. Calvin, neurophysiologist and author of How Brains > Think. > > > For more > information, see: <http://www.davidbrin.com/>http://www.davidbrin.com/ > -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) God is silent. Now if we can only get Man to shut up. </x-flowed> --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

None
by John Denker 06 Jul '18

06 Jul '18

Gecko/20041007 Debian/1.7.3-5 To: Udhay Shankar N <udhay(a)pobox.com> Cc: cryptography(a)metzdowd.com Subject: Re: Conspiracy Theory O' The Day Sender: owner-cryptography(a)metzdowd.com Udhay Shankar N wrote: > I just got a batch of spam: perfectly justified blocks of random-looking > characters. Makes me wonder if somebody is trying to train Bayesian > filters to reject PGP messages. Another hypothesis: Cover traffic, to defeat traffic analysis. The procedure: send N copies. N-M of them are spam, sent to uninterested parties. The other M parties are the intended recipients. Provided N>>M, and other mild restrictions, they achieve plausible deniability. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

[serval-project-dev] Someone has started work on something we have been planning for a while ...
by Paul Gardner-Stephen 06 Jul '18

06 Jul '18

http://code.google.com/p/twimight/ It is a twitter client for Android that features a P2P mode for when there is no internet access. Always encouraging to see this kind of thing getting underway. It is still early days for them by the look of things, but I will have a chat with them about integrating with our (not yet existent) APIs for accessing the Serval MeshMS, Meow (more on that when we can work up the documentation) and other relevant services. Paul. -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [hackerspaces] Academic scraping
by Bryan Bishop 06 Jul '18

06 Jul '18

On Mon, Jan 14, 2013 at 11:51 AM, Lokkju Brennr wrote: > see: > http://scraperwiki.org > http://scrapy.org/ > > Once you have the raw data in a central location, it becomes much easier for > someone specialized in data processing to convert it to usable form - even > if it is hard to parse. It does help to keep the metadata though... One of my favorite scraping methods at the moment is phantomjs, a headless wrapper around webkit. http://phantomjs.org/ https://github.com/ariya/phantomjs https://github.com/kanzure/pyphantomjs But for academic projects, I highly recommend zotero's translators. https://github.com/zotero/translators Here's why. There's already a huge userbase of zotero users actively updating these scrapers. When they break, they fix them immediately. They are all written in javascript and they extract not only the link to the pdf but also the maximum amount of metadata. With the help of the zotero/translation-server project, they can be used headlessly. https://github.com/zotero/translation-server I have a demo of this working in irc.freenode.net ##hplusroadmap (paperbot), he just grabs links from our conversation and posts the pdfs so that we don't have to ask each other for copies. - Bryan http://heybryan.org/ 1 512 203 0507 -- You received this message because you are subscribed to the Google Groups "science-liberation-front" group. To unsubscribe from this group, send email to science-liberation-front+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [Freedombox-discuss] Store-and-forward is a necessity
by Jay Sulzberger 06 Jul '18

06 Jul '18

On Wed, 2 Mar 2011, Luke Kenneth Casson Leighton <luke.leighton(a)gmail.com> wrote: > just some random comments along similar lines: > > * like UUCP, SMTP was also designed to be resilient in the face of > significant disconnects and down-time. many people forget this due to > its abuse for spam... :) (no, you do not have to use SMTP _just_ for > transferring mail, as we well know. i say this explicitly to avoid > any assumptions that i have said "yes! use SMTP! And Only For > Email!") > > * nmbd (part of samba) - actually RFC1001 and RFC1002 - has the > problem of disappearing unreliable hosts solved for... decades. it's > just not very well understood or appreciated that that's nmbd does. > doing peer-to-peer multi-LAN host detection and communicating host > availability network-wide is f*****g hard to get right. back in > 1997-9 at the CIFS conferences, we found that EVERY single implementor > of RFC1001/1002 takes about THREEEE years to get the implementation > correct. INCLUDING microsoft themselves! apt-cache show samba > > *avahi is a piece of shit by comparison to what nmbd can do: it's just > that everyone, when they hear the words "microsoft" and "network > neighbourhood", turns their back on nmbd, pulls their trousers down > and strains mightily to heave out a steaming turd in its general > direction, rather than recognise the value of what nmbd has provided. > think about this: DESPITE completely ignorant computer users > completely screwing up their network configurations, systems based > around the "network neighbourhood" _still_ work... :) > > * n2n is a peer-to-peer Layer 2 VPN (similar to openvpn). its only > flaw is that it requires all parties to agree a "key", and no > mechanism has been provided to "negotiate" such a key. apt-cache show > n2n > > * babel is a mathematically-provably-correct routing algorithm that > can be used to replace BGP. every system participates in the routing, > and there is no dependence on any one given system. apt-cache show > babeld > > also... hah! it looks like there is something on top of babeld, > called ahcpd - wooow. i hadn't heard of that one, before, until > today. > > so - just food for thought: the pieces of the puzzle, to provide > resilient large-scale networking and communications infrastructure, > even in the face of absolutely zero "central servers", are beginning > to appear. > > and the nice thing is - these are all debian packages. > > the only thing i _haven't_ been able to find is a peer-to-peer DNS > service, but i beliieeeeve that there is someone working on that. ok. > they were _supposed_ to be: http://groups.google.com/group/dns-p2p - > ahh, actually someone's made an effort: > https://github.com/Mononofu/P2P-DNS > > so. there exists solid, real-world debian packages for the basics > behind the networking. as debian packages. that's really good. > > l. I have glanced at the documentation of the remarkable work of Zooko O'Whielacronx and the Tahoe team: http://tahoe-lafs.org/trac/tahoe-lafs And ZRTP: http://en.wikipedia.org/wiki/ZRTP may help us to produce a system of encrypted file-transfer/email/general-over-the-Net-communication which meets my standard constraint: Two people who have Net connected computers behind NAT/fire/proxy walls can spend ten minutes on the phone and set up the link; only one of the two need have heard of the link software before the telephone call. oo--JS. _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [Freedombox-discuss] Store-and-forward is a necessity
by Jay Sulzberger 06 Jul '18

06 Jul '18

On Wed, 2 Mar 2011, Luke Kenneth Casson Leighton <luke.leighton(a)gmail.com> wrote: > just some random comments along similar lines: > > * like UUCP, SMTP was also designed to be resilient in the face of > significant disconnects and down-time. many people forget this due to > its abuse for spam... :) (no, you do not have to use SMTP _just_ for > transferring mail, as we well know. i say this explicitly to avoid > any assumptions that i have said "yes! use SMTP! And Only For > Email!") > > * nmbd (part of samba) - actually RFC1001 and RFC1002 - has the > problem of disappearing unreliable hosts solved for... decades. it's > just not very well understood or appreciated that that's nmbd does. > doing peer-to-peer multi-LAN host detection and communicating host > availability network-wide is f*****g hard to get right. back in > 1997-9 at the CIFS conferences, we found that EVERY single implementor > of RFC1001/1002 takes about THREEEE years to get the implementation > correct. INCLUDING microsoft themselves! apt-cache show samba > > *avahi is a piece of shit by comparison to what nmbd can do: it's just > that everyone, when they hear the words "microsoft" and "network > neighbourhood", turns their back on nmbd, pulls their trousers down > and strains mightily to heave out a steaming turd in its general > direction, rather than recognise the value of what nmbd has provided. > think about this: DESPITE completely ignorant computer users > completely screwing up their network configurations, systems based > around the "network neighbourhood" _still_ work... :) > > * n2n is a peer-to-peer Layer 2 VPN (similar to openvpn). its only > flaw is that it requires all parties to agree a "key", and no > mechanism has been provided to "negotiate" such a key. apt-cache show > n2n > > * babel is a mathematically-provably-correct routing algorithm that > can be used to replace BGP. every system participates in the routing, > and there is no dependence on any one given system. apt-cache show > babeld > > also... hah! it looks like there is something on top of babeld, > called ahcpd - wooow. i hadn't heard of that one, before, until > today. > > so - just food for thought: the pieces of the puzzle, to provide > resilient large-scale networking and communications infrastructure, > even in the face of absolutely zero "central servers", are beginning > to appear. > > and the nice thing is - these are all debian packages. > > the only thing i _haven't_ been able to find is a peer-to-peer DNS > service, but i beliieeeeve that there is someone working on that. ok. > they were _supposed_ to be: http://groups.google.com/group/dns-p2p - > ahh, actually someone's made an effort: > https://github.com/Mononofu/P2P-DNS > > so. there exists solid, real-world debian packages for the basics > behind the networking. as debian packages. that's really good. > > l. I have glanced at the documentation of the remarkable work of Zooko O'Whielacronx and the Tahoe team: http://tahoe-lafs.org/trac/tahoe-lafs And ZRTP: http://en.wikipedia.org/wiki/ZRTP may help us to produce a system of encrypted file-transfer/email/general-over-the-Net-communication which meets my standard constraint: Two people who have Net connected computers behind NAT/fire/proxy walls can spend ten minutes on the phone and set up the link; only one of the two need have heard of the link software before the telephone call. oo--JS. _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[tahoe-lafs-weekly-news] TWN #14
by Patrick R McDonald 06 Jul '18

06 Jul '18

o;?========================================================= Tahoe-LAFS Weekly News, issue number 14, October 10, 2011 ========================================================= Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS_ is a secure, distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_. If you would like to view the "new and improved" TWN, complete with pictures; please take a `look`_. .. _Tahoe-LAFS: http://tahoe-lafs.org .. _View TWN on the web: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: http://tahoe-lafs.org/~marlowe/TWN14.html Announcements and News ====================== Tahoe-LAFS v1.8.3 Released -------------------------- The Tahoe-LAFS project released version 1.8.3_ and 1.9.0a2 to address a security issue. A vulnerability was discovered in all versions from 1.3.0 to 1.8.2 and 1.9.0a1. This vulnerability allowed a malicious attacker to delete files. To be able to delete the file, an attacker must know its 'storage index'. An upgrade to 1.8.3 resolves this issues. The `known issues document`_ provides the technical information regarding this issue. .. _1.8.3: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006675.html .. _known issues document: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/known_issues.rst Announcing the Second International Tahoe-LAFS Summit ----------------------------------------------------- The *Second International Tahoe-LAFS Summit* will take place November 7 through November 11, in San Francisco. `Mozilla`_ |mozilla| has generously offered to host us in their nice new San Francisco office. (`Google`_ |google|, `Adobe`_ |adobe|, and `Microsoft`_ |microsoft| also offered to help out in case Mozilla's facilities weren't availablebthanks to them as well.) The Summit will have technical presentations of new features, design discussions, and probably a lot of coding! There will be live audio and video available for remote participants. `Help us organize the Summit`_ on the wiki. .. _Help us organize the Summit: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit .. _Mozilla: https://www.mozilla.org .. |mozilla| image:: Mozilla_logo-35x35.svg :height: 35 :alt: Mozilla :target: https://www.mozilla.org .. _Google: https://google.com .. |google| image:: Google-logo-x35.svg :height: 35 :alt: Google :target: https://google.com .. _Adobe: https://www.adobe.com .. |adobe| image:: Adobe_logo-x35.svg :height: 35 :alt: Adobe :target: https://www.adobe.com .. _Microsoft: https://www.microsoft.com .. |microsoft| image:: Microsoft_Logo_Historical.svg :height: 25 :alt: Microsoft :target: https://www.microsoft.com 1.9.0a2 Release --------------- 1.9.0a2_ was released. In addition to the security fix mentioned above, this release incorporates the following fixes: * 'tahoe debug' commands now understand MDMF caps and shares (`#1507`_) * Recent Uploads And Downloads shouldn't miss 'tahoe put' (`#1079`_) * tests run slightly faster, still kinda painful * 'tahoe put --mutable-type=.." implies --mutable * fewer dropped errors (and lost-progress bugs) in mutable retrieve * tolerate linux-3.0 in platform detection code (`#1536`_) The following work remains for the 1.9.0 release: * docs improvements * minor fixes: really really minor * packaging tests * Foolscap needs a new release, so make sure Tahoe-LAFS is compatible We highly encourage everyone to throughly test this release. The more bugs we find in the alpha, the less in the beta and the quicker 1.9.0 arrives. Currently, there is a possibility of a Halloween release of 1.9.0. .. _1.9.0a2: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006697.html .. _#1507: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1507 .. _#1079: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1079 .. _#1536: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1536 tahoe-lafs.org Outage --------------------- tahoe-lafs.org `experienced multiple outages`_ over the last several days. The outages were the result of a router which was acting up. The router has been replaced. We apologize for any inconvenience these outages may have caused. We are in the process of migrating the server to a new virtual server with professional hosting instead of being an old server humming away in someone's garage. .. _experienced multiple outages: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-October/006701.html Free/Open Source Project of the Week ==================================== The *Free/Open Source Project of the Week* is HekaFS_, formerly known as "CloudFS". Like Tahoe-LAFS, HekaFS offers provider-independent confidentiality by encrypting all of the data on the client side, with an encryption key unknown to the server. It is built on top of GlusterFS_, and it inherits most of the performance and scalability of GlusterFS. It also has the same network and filesystem semantics of GlusterFS. In contrast, Tahoe-LAFS invents new semantics such as provider-independent immutability. The HekaFS project is lead by Jeff Darcy |jeffdarcy| and sponsored by RedHat |redhat|. In addition to sponsoring HekaFS, RedHat just announced that they are buying the Gluster company. .. _HekaFS: http://hekafs.org .. _GlusterFS: http://gluster.org .. |jeffdarcy| image:: jeff_darcy-bw.png :height: 35 :alt: Jeff Darcy :target: http://pl.atyp.us .. |redhat| image:: RedHat-logo-x35.svg :height: 35 :alt: RedHat :target: https://www.redhat.com/ Commercial Supporter of the Week ================================ The Tahoe-LAFS project would like to thank `Atlas Networks`_ |AtlasNetworks| for their generous donation of four servers. In addition to the generosity of their hardware donation, Atlas Networks provide the Tahoe-LAFS project with remote consoles and technical support, including complete OS reinstalls. .. _Atlas Networks: http://atlasnetworks.us .. |AtlasNetworks| image:: AtlasNetworks.png :height: 35 :alt: Atlas Networks :target: http://atlasnetworks.us >From the tahoe-dev Mailing List =============================== Performance Measurements ------------------------ Brian Warner |brian| has been using the Atlas Networks servers to do performance measurements of Tahoe-LAFS. These measurements `show some performance issues`_, including one that arises when using large values of K (number of shares needed). Ticket 1264_ has details. .. _1264: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1264 .. _show some performance issues: .. http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006683.html Tahoe-LAFS web-app ------------------ Brian Warner `suggested`_ the notion of a "Tahoe-LAFS web-app", in which both the data and the code (Javascript) are stored in a Tahoe-LAFS grid and the browser loads them and runs the Javascript app. This would have a similar effect to the `TiddlyWiki-on-Tahoe-LAFS`_ hack, and to the `Unhosted`_ |unhosted| project. .. _TiddlyWiki-on-Tahoe-LAFS: http://tahoe-lafs.org/trac/tiddly_on_tahoe .. _Unhosted: http://unhosted.org .. _suggested: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006690.html .. |unhosted| image:: unhosted-logo.png :height: 35 :alt: Unhosted :target: http://unhosted.org Ifconfig Error Message ---------------------- Kill Your TV posted an issue with `Arch Linux and 1.8.3`_. The issue was the result of the inability of tahoe to find ifconfig. Ticket `#1536`_ was opened to provided more user friendly error messages involving finding and using ifconfig. .. _Arch Linux and 1.8.3: .. http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006676.html Patch Needing Review of the Week ================================ There are six (6) tickets still needing review for 1.9: * 393_: MDMF * 1265_: New Visualizer is insufficiently labelled/documented (plus layout problem) * 1398_: make docs/performance.rst more precise and accurate * 1547_: the WUI controls for setting the type of an uploaded file are confusing * 1552_: web-API: replace ?mutable-type with ?format={chk,sdmf,mdmf} * 1556_: fix bugs found by 'check-miscaptures' script Let's see if we can't get these reviewed and 1.9 out the door. .. _393: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393 .. _1265: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265 .. _1398: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1398 .. _1547: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1547 .. _1552: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1552 .. _1556: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1556 ---- *The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS* *Software Foundation, President and Treasurer: Peter Secor* |peter| *. Scribes: Patrick "marlowe" McDonald* |marlowe| *, Zooko Wilcox-O'Hearn* |zooko| *, Editor: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_ *. Send your news stories to* `marlowe(a)antagonism.org`_ *b submission deadline: Friday night.* .. _marlowe(a)antagonism.org: mailto:marlowe@antagonism.org .. |zooko| image:: zooko.png :height: 35 :alt: zooko :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |brian| image:: warner.png :height: 35 :alt: brian :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |peter| image:: psecor.jpg :height: 35 :alt: peter :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |marlowe| image:: marlowe-x75-bw.jpg :height: 35 :alt: marlowe :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0