July 2018 - cypherpunks-legacy

OnionCat News
by Bernhard Fischer 06 Jul '18

06 Jul '18

OnionCat (http://www.cypherpunk.at/onioncat/) is getting more stable and we successfully ported it to several OSes, most notably WindowsXP. Unfortunately we still lag behind with documentation but we have tasks to enhance this part. Currently it seems to run stable on and was explicitly ported to (*) Windows XP (Cygwin) (*) Linux (*) OpenBSD (*) FreeBSD (*) MacOSX For Windows we are working on an installation package, for installation from source have a look at http://www.cypherpunk.at/. Ubuntu package is ready (http://www.cypherpunk.at/onioncat/wiki/Download) Debian package is under construction. The debuild sources already exists within the svn tree. OnionCat is checked in into OpenBSD ports tree -- unfortunately exactly that revision segfaults but an update will follow after release of OpenBSD 4.5. On FreeBSD it will be checked in soon and also a MacOSX package will follow. The Solaris port is already under construction. Additional development is undertaken to build a special adapter (Socks5) for I2P. This will make OC run with Tor and I2P. For further information have a look at http://www.cypherpunk.at/onioncat/ . Don't hesitate to contact me personally or register to our mailinglist ocat-talk(a)cypherpunk.at (ocat-talk-subscribe(a)cypherpunk.at) Best regards, Bernhard ----- 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-announce] ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0N2
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: Please try this out! I think this version is reliable and performs well and will become the v1.8.0 final release in less than two weeks' time. Send your results to tahoe-dev(a)tahoe-lafs.org or if you find an issue add it to the issue tracker at http://tahoe-lafs.org . Thanks! :-) Regards, Zooko ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0N2 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.8.0N2 of Tahoe-LAFS, an extremely reliable distributed storage system. Tahoe-LAFS is the first distributed storage system which offers "provider-independent security"bmeaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html The current stable release of Tahoe-LAFS is v1.7.1, which was released July 18, 2010 [1]. v1.8.0N2 is the beta release of major new improvements, including fast and fault-tolerant downloads and better Windows support. See the NEWS file [2] for details. If no regressions or critical bugs are discovered in this 1.8.0N2 version then we will release a functionally identical 1.8.0 final version on approximately August 15, 2010. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers are compromised by by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems. These include frontends for Windows, Macintosh, JavaScript, iPhone, and Android, and plugins for Hadoop, bzr, mercurial, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or "cloud storage" systems. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all currently known issues please see the known_issues.txt file [4].) COMPATIBILITY This release is fully compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the eleventh release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.html" [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they have continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Thank you to Allmydata, Inc. for their generous and public-spirited support. Google, Inc. is sponsoring Tahoe-LAFS development as part of the Google Summer of Code 2010. Google suggested that we should apply for the Summer of Code program, and when we did they generously awarded four sponsorships to students from around the world to hack on Tahoe-LAFS this summer. Thank you to Google, Inc. for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [12]. ACKNOWLEDGEMENTS This is the fifth release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. David-Sarah Hopwood and Zooko Wilcox-O'Hearn on behalf of the Tahoe-LAFS team August 3, 2010 Rainhill, Merseyside, UK and Boulder, Colorado, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4579 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=4636 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.txt [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=4591 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-announce ----- 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

OnionCat News
by Bernhard Fischer 06 Jul '18

06 Jul '18

OnionCat (http://www.cypherpunk.at/onioncat/) is getting more stable and we successfully ported it to several OSes, most notably WindowsXP. Unfortunately we still lag behind with documentation but we have tasks to enhance this part. Currently it seems to run stable on and was explicitly ported to (*) Windows XP (Cygwin) (*) Linux (*) OpenBSD (*) FreeBSD (*) MacOSX For Windows we are working on an installation package, for installation from source have a look at http://www.cypherpunk.at/. Ubuntu package is ready (http://www.cypherpunk.at/onioncat/wiki/Download) Debian package is under construction. The debuild sources already exists within the svn tree. OnionCat is checked in into OpenBSD ports tree -- unfortunately exactly that revision segfaults but an update will follow after release of OpenBSD 4.5. On FreeBSD it will be checked in soon and also a MacOSX package will follow. The Solaris port is already under construction. Additional development is undertaken to build a special adapter (Socks5) for I2P. This will make OC run with Tor and I2P. For further information have a look at http://www.cypherpunk.at/onioncat/ . Don't hesitate to contact me personally or register to our mailinglist ocat-talk(a)cypherpunk.at (ocat-talk-subscribe(a)cypherpunk.at) Best regards, Bernhard ----- 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-announce] ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0N2
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: Please try this out! I think this version is reliable and performs well and will become the v1.8.0 final release in less than two weeks' time. Send your results to tahoe-dev(a)tahoe-lafs.org or if you find an issue add it to the issue tracker at http://tahoe-lafs.org . Thanks! :-) Regards, Zooko ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0N2 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.8.0N2 of Tahoe-LAFS, an extremely reliable distributed storage system. Tahoe-LAFS is the first distributed storage system which offers "provider-independent security"bmeaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html The current stable release of Tahoe-LAFS is v1.7.1, which was released July 18, 2010 [1]. v1.8.0N2 is the beta release of major new improvements, including fast and fault-tolerant downloads and better Windows support. See the NEWS file [2] for details. If no regressions or critical bugs are discovered in this 1.8.0N2 version then we will release a functionally identical 1.8.0 final version on approximately August 15, 2010. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers are compromised by by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems. These include frontends for Windows, Macintosh, JavaScript, iPhone, and Android, and plugins for Hadoop, bzr, mercurial, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or "cloud storage" systems. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all currently known issues please see the known_issues.txt file [4].) COMPATIBILITY This release is fully compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the eleventh release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.html" [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they have continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Thank you to Allmydata, Inc. for their generous and public-spirited support. Google, Inc. is sponsoring Tahoe-LAFS development as part of the Google Summer of Code 2010. Google suggested that we should apply for the Summer of Code program, and when we did they generously awarded four sponsorships to students from around the world to hack on Tahoe-LAFS this summer. Thank you to Google, Inc. for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [12]. ACKNOWLEDGEMENTS This is the fifth release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. David-Sarah Hopwood and Zooko Wilcox-O'Hearn on behalf of the Tahoe-LAFS team August 3, 2010 Rainhill, Merseyside, UK and Boulder, Colorado, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4579 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=4636 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.txt [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=4591 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-announce ----- 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

<nettime> NYT > Krugman > The New Hungarian Secret Police
by nettime's_roving_reporter 06 Jul '18

06 Jul '18

<http://krugman.blogs.nytimes.com/2012/04/19/the-new-hungarian-secret-police/> April 19, 2012, 6:59 pm The New Hungarian Secret Police Another Hungary post from my Princeton colleague Kim Lane Scheppele, after the jump. The New Hungarian Secret Police Kim Lane Scheppele Tuesday 17 April 2012 Brad Pitt knows all about the TEK, Hungary's new counter-terrorism police. When Pitt was in Budapest last October shooting World War Z, an upcoming zombie-thriller, TEK agents [42]seized 100 machine guns, automatic pistols and sniper rifles that had been flown to Hungary for use as props in the movie. The weapons were disabled and came with no ammunition. But the Hungarian counter-terrorism police determined that they constituted a serious threat. The dead-pan seizure of movie props made TEK the laughing stock of the world. As David Itzkoff [43]joked in the pages of the New York Times, "If Hungary ever finds itself the target of an undead invasion, its police force should now be well supplied to defend the nation." Few have taken TEK seriously. But that is a big mistake. In fact, TEK seems to be turning into Prime Minister Viktor Orban's own secret police. In less than two years, TEK has amassed truly Orwellian powers, including virtually unlimited powers of secret surveillance and secret data collection. The speaker of the Parliament, Laszls Kvvir, now has his own armed guard too, since the Parliament yesterday passed a law that creates a separate armed police force accountable to the Parliament. It too has extraordinary powers not normally associated with a Parliamentary guard. The creation of this "Parlia-military" gives Hungary the dubious distinction of having the only Parliament in Europe with its own armed guard that has the power to search and "act in" private homes. About the Parlia-military, more later. First, to TEK. TEK was created in September 2010 by a governmental decree, shortly after the Fidesz government took office. TEK exists outside the normal command structure of both the police and the security agencies. The Prime Minister directly names (and can fire) its head and only the interior minister stands between him and the direct command of the force. It is well known that the head of this force is a very close confidante of the Prime Minister. TEK was set up as an anti-terror police unit within the interior ministry and given a budget of 10 billion forints (about $44 million) in a time of austerity. Since then, it has grown to nearly 900 employees in a country of 10.5 million people that is only as big as Indiana. Why was TEK necessary? When it was created, the government said that it needed TEK because Hungary would hold the rotating presidency of the European Union starting in January 2011. During the six months it held this office, Hungary could be expected to host many important meetings for which top anti-terrorism security would be necessary. But even though Hungary's stint in the EU chair is over, TEK has continued to grow. Eyebrows were raised when Janos Hajdu, Orban's personal bodyguard, was appointed directly by the prime minister to be the first head of this new agency. Since TEK's job also included guarding the prime minister, some believed that Orban had set up the office to get his trusted bodyguard onto the public payroll. Patronage turns out to be the least of the worries about TEK, however. TEK is now the sort of secret police that any authoritarian ruler would love to have. Its powers have been added slowly but surely through a series of amendments to the police laws, pushed through the Parliament at times when it was passing hundreds of new laws and when most people, myself included, did not notice. The new powers of TEK have received virtually no public discussion in Hungary. But now, its powers are huge. What can the TEK do? TEK can engage in secret surveillance without having to give reasons or having to get permission from anyone outside the cabinet. In an amendment to the police law passed in December 2010, TEK was made an official police agency and was given this jurisdiction to spy on anyone. TEK now has the legal power to secretly enter and search homes, engage in secret wiretapping, make audio and video recordings of people without their knowledge, secretly search mail and packages, and surreptitiously confiscate electronic data (for example, the content of computers and email). The searches never have to be disclosed to the person who is the target of the search - or to anyone else for that matter. In fact, as national security information, it may not be disclosed to anyone. There are no legal limits on how long this data can be kept. Ordinary police in Hungary are allowed to enter homes or wiretap phones only after getting a warrant from a judge. But TEK agents don't have to go to a judge for permission to spy on someone - they only need the approval of the justice minister to carry out such activities. As a result, requests for secret surveillance are never reviewed by an independent branch of government. The justice minister approves the requests made by a secret police unit operated by the interior minister. Since both are in the same cabinet of the same government, they are both on the same political team. TEK's powers were enlarged again in another set of amendments to the police law passed on 30 December 2011, the day that many other laws were passed in a huge end-of-year flurry. With those amendments, TEK now has had the legal authority to collect personal data about anyone by making requests to financial companies (like banks and brokerage firms), insurance companies, communications companies (like cell phone and internet service providers) - as well as state agencies. Data held by state agencies include not only criminal and tax records but also educational and medical records - and much more. Once asked, no private company or state agency may refuse to provide data to TEK. Before December 2011, TEK had the power to ask for data like this, but they could only do so in conjunction with a criminal investigation and with the permission of the public prosecutor. After December 2011, their data requests no longer had to be tied to criminal investigations or be approved by the prosecutor. In fact, they have virtually no limits on what data they can collect and require no permission from anyone. If an organization (like an internet service provider, a bank or state agency) is asked to turn over personally identifiable information, the organization may not tell anyone about the request. People whose data have been turned over to TEK are deliberately kept in the dark. These powers are shocking, not just because of their scope, but also because most Hungarians knowledgeable about constitutional law would probably have thought they were illegal. After the changes of 1989, the new Hungarian Constitutional Court was quick to dismantle the old system in which the state could compile in one place huge amounts of personal information about individuals. In its "PIN number" decision of 1991, the Constitutional Court ruled that the state had to get rid of the single "personal identifier number" (PIN) so that personally identifiable data could no longer be linked across state agencies. The Court found that "everyone has the right to decide about the disclosure and use of his/her personal data" and that approval by the person concerned is generally required before personal data can be collected. It was the essence of totalitarianism, the Court found, for personal information about someone to be collected and amassed into a personal profile without the person's knowledge. With that Constitutional Court decision still on the books and not formally overruled, the Fidesz government is reproducing the very system that the Court had banned by creating a single agency that can gather all private information about individuals in one place again. What, one might ask, is left of constitutional law in Hungary? One might also ask: Are there any limits to TEK's power? The law specifies that TEK operates both as a police and as a national security agency. When it is acting as a police unit, it has the jurisdiction to spy on any person or group who poses a threat of terrorism, along with anyone else associated with such persons. Hungary, like many countries after 9/11, has a broad definition of terrorism that includes, among other things, planning to commit a "crime against the public order" with the purpose of "coercing a state body . . . into action, non-action or toleration." Crimes against the public order include a long list of violent crimes, but also the vaguer "causing public danger." In addition, TEK also may arrest "dangerous individuals," a term not defined in the criminal law. It is difficult from the text of the law itself to see any clear limits on TEK's powers. And TEK is very active. On April 7, TEK agents were called in to [44]capture a young man in the small village of Kulcs who killed four members of his family with a machete. And then, in the early morning hours of Friday, April 13, TEK agents conducted a major drug bust in Budapest, arresting 23 people. According to news reports, fully 120 TEK agents were involved in the drug operation, [45]raising questions about whether the drug bust was thought to be part of the anti-terrorism mission of the agency or a rather broad extension of the concept of the "dangerous individual." Either way, the drug ring looked like garden-variety crime. If that is within TEK's jurisdiction, it is hard to imagine what is not. A You-Tube video of the April 13 drug bust, made available by TEK itself, shows what a middle-of-the-night raid by TEK officers looks like, complete with the use of heavy-duty tools to cut open an exterior door. IFRAME: [46]http://www.youtube.com/embed/Trl2YSiawXk Given that this is the video that TEK wanted you to see, one can only imagine the activities of TEK that are not recorded for posterity. (It would be interesting to know, for example, why the audio cuts out at certain points in the clip, as well as what happens between the time that TEK breaks open the door and the time the various suspects are seen lying handcuffed on the floor.) While its videos are crystal clear, TEK's legal status is blurry, as some parts of its activities are authorized under the police law and others parts are authorized under the national security law. Different rules and standards apply to police agencies and to national security agencies. Moreover, TEK seems to have some powers that exceed those of both police and national security agencies, particularly in its ability to avoid judicial warrants. No other agency in the Hungarian government has both police and national security powers, and it is unclear precisely how the agency is accountable - for which functions, under what standards and to whom. What follows is my best guess from reading the law. With respect to its powers authorized under the police law, it appears that TEK must act like the police and get judicial warrants to search houses, to wiretap and to capture electronic data when these activities are part of a criminal investigation. When TEK was arresting the machete-wielder and making the drug bust, it was probably acting under its police powers. But TEK only need judicial warrants when it is engaged in criminal investigations. It doesn't need judicial warrants when it is using its secret surveillance powers in security investigations. When it is acting as a national security agency, TEK only needs the permission of the justice minister to engage in secret and intrusive surveillance. Of course, given that the permissions and constraints are different depending on whether TEK is acting as a police agency or a national security agency, it would matter who decides whether a particular activity is conducted for police or national security purposes and what the criteria are for determining that it is one or the other. The law does not provide the answer to either question. Suppose someone believes that she has been spied upon illegally by TEK. What can she do to object? First, if TEK is engaged in secret surveillance or data collection, it is unlikely that people will know that they are a target, given the extraordinary secrecy of the whole operation. But even if one finds out that one is being watched, the remedies are not encouraging. A person aggrieved by TEK's actions may complain to the interior minister, and the interior minister must answer the complaint within 30 days. But given that the interior minister is the minister who controls TEK in the first place, this is not an independent review. If the complainant does not like the answer of the interior minister, s/he may appeal to the Parliament's national security committee, which must muster a one-third vote to hear the petition. At the moment, the 12-member national security committee consists of two-thirds governing party members and one-third members of all other parties combined. If the governing party does not want to investigate a complaint, garnering a one-third vote would mean uniting the whole opposition - or, to put it in more blunt terms, getting the Socialists to work with the neo-Nazis. That is unlikely to happen. Even if the national security committee agrees to hear a petition, however, it would take a two-thirds vote of the committee to require the interior minister to reveal the surveillance methods used against the complainant so that the committee can determine whether they were legal. There is no judicial review at any stage of this process. TEK operates in secret with extraordinary powers and no one reliably independent of the current governing party can review what it is doing when it uses its most potentially abusive powers. This shocking accumulation of power may explain the Hungarian government's abolition of a separate data protection ombudsman who would have the power to investigate such shocking accumulation of data. Instead, the data protection officer - a post required by European Union law - has been made a political appointee of the government itself. This is why the EU has [47]launched an infringement action against Hungary for failing to guarantee the independence of the office. Now we can see why the EU may be onto something. As if the powers of TEK are not enough, though, Parliament yesterday authorized another security service with the power to use police measures against citizens and residents of Hungary. The cardinal law on the Parliament itself contains a provision that gives the Parliament its own military, a Parlia-military. The Parlia-military is an armed police unit outside the chain of command of the regular military or police structures. Its commander in chief is the speaker of the house, Laszls Kvvir, who served as minister without portfolio for the Civilian Intelligence Services during the first Orban government from 1998-2002. The Parlia-military has the power to guard the Parliament and the speaker of the house, as might be expected. But if the Parlia-military is only supposed to guard the Parliament and the speaker, why does it need the powers that the cardinal law gives it? The law gives the Parlia-military power "to enter and to act in private homes." That's literally what the law says. It is unlikely that the Parliament will want to conduct a plenary session in someone's living room, so one must then wonder just what the Parliament will do if its armed military enters someone's home to "act." In addition to this power, the Parlia-military may also make public audio and video recordings of people. It can also search cars, luggage and clothing. It can use handcuffs and chemical substances (which I assume means tear gas and nothing more, but the wording make it sound like the Parlia-military may use chemical weapons!). The draft law seems to imply that the Parlia-military would have to operate under the constraints of the police law, which would mean that it would need judicial warrants to conduct these intrusive measures. But that is not completely clear. What is clear is that Hungary now suffers from a proliferation of police that are under direct political control. Until this point, I have thought that the Fidesz government was just attempting to lock down power for itself for the foreseeable future, which was bad enough. But now, with the discovery of these new security services, it seems increasingly likely that the Hungarian government is heading toward the creation of a police state. Actually, it may already be there. But shhhh! It's secret. B) 2012 The New York Times Company # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- 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: [HacDC:Byzantium] I'd like to help out
by Dave Duchesneau 06 Jul '18

06 Jul '18

> "Rooting the phone will allow for adhoc mesh network capability and is > required for full functionality of the software. By choosing not to > root the phone, the software will still be able to provide free calls > to phones that are connected to the same Access Point." AFAIK, although Serval currently requires a rooted phone for the phone itself to be part of the mesh, the standard Serval download for Android allows phone-to-phone communications through an AP with a non-rooted phone. This is more of a fallback plan, since a key aspect of the Serval project is to have the phones be mesh nodes. However, as one may surmise, even such AP-based communications would not be possible if the AP is configured to disallow client-to-client communications (i.e., client isolation mode). On the other hand, if the AP is really just an SSID offered by the nodes on a bridged mesh network, then AP-based Serval communications may reach anywhere that the underlying mesh network reaches. Because such a network is in bridged mode, it operates at layer 2 (based on MAC addresses), and thus is effectively a big software switch, so collectively, all the nodes act as one big AP (in some configurations, clients can roam between mesh nodes without losing sessions, IP addresses, etc.). For those who may not be aware, two examples of such bridged mesh networks are the open-source SECN offering from Village-Telco.org (which is also collaborating with the Serval project to make their meshes interoperate), and also Open-Mesh.com (providing the bridge-mode option is selected). Both meshes are based on batman-adv, so you could expect similar behavior from any mesh based on batman-adv (in bridge mode), and possibly other bridged meshes. Bridged meshes are relatively straightforward, but are not without issues, especially with respect to scalability. One avenue to address scalability issues is to adopt hybrid models where layer 2 is used for localized mesh clusters (up to 20-200 nodes, let's say), and layer 3 is used to route between localized mesh clusters. Note that with a hybrid approach, layer 3 may also serve as an interoperability layer to connect meshes with differing protocols, so that Byzantium-style OLSR meshes may be routed to VillageTelco-style batman-adv meshes. Layer 3 routing consumes more resources than layer 2, so such an approach may not be feasible on every mesh node. Of course, multiple protocols may coexist on run-of-the-mill mesh nodes, too, if there's enough local capacity (memory, CPU, radio bandwidth, etc.). In general, it would be good to make all the meshes work together, at least at arm's length (i.e., this can be done a non-trusted basis, assuming end-to-end encryption). To maximize communications survivability, our own approach incorporates a smattering of optional multi-radio nodes (multiple bands, channels, protocols) in every mesh. These nodes have extra capacity for routing, proxying, protocol translation, serving, store-and-forward, caching, etc. Preachin' to the Choir, Dave Duchesneau ddd(a)crisis-force.org CRISIS-FORCE Emergency Network -----Original Message----- From: Ben Mendis [mailto:dragonwisard@gmail.com] Sent: Tuesday, June 19, 2012 5:20 AM To: byzantium(a)hacdc.org Subject: Re: [HacDC:Byzantium] I'd like to help out -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It may be accurate. I may have misunderstood something. I haven't gotten an opportunity to test out Serval myself yet. On Tue, 19 Jun 2012, John wrote: > On 6/12/2012 11:40 AM, Ben Mendis wrote: >> It seems that Serval (http://www.servalproject.org/) has >> managed to get BATMAN-Adv to run as an Android app without requiring >> root, so maybe it's possible for Babel and OLSR too. > > Does that mean this document is out-of-date? > > http://developer.servalproject.org/files/Serval_Manual_Prototype_v0.05.pdf > > Scroll down to 2.3, > "Rooting the phone will allow for adhoc mesh network capability and is > required for > full functionality of the software. By choosing not to root the phone, the > software > will still be able to provide free calls to phones that are connected to the > same > Access Point." > > John > > -- > You received this message because you are subscribed to the Google Groups > "Project Byzantium (Emergency Mesh Networking)" group. > To post to this group, send email to Byzantium(a)hacdc.org. > To unsubscribe from this group, send email to > Byzantium+unsubscribe(a)hacdc.org. > For more options, visit this group at > http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJP4G57AAoJEMco5sYyM+0wq58H/RmhKlbWA7prhiD2CaJS0h4s SVH9Wj/HfFh2D3Rs25gyOYnZ/o05/KRMS38MSNCDrUxg9uqqUavZ+85I2yfw6XKJ p905Ejo0E1SXpiWpxtTeZ3J8ZKQP5vTFa0NTSs07U0dCE1h59vTkEdjA8cQk6oEc z0yytSLlXNa9okLof1AK6U0m0Jjdkps/NcjScQFOsuJ0gT4SYluzecrV2E5UL/tI HFqtdsxvtil8m9xnmVfg7z3GvqhpCbPxVMVsCEvWXCSDiVL6euw/a4Usz3/8IBps 8TCiYnkQvZvtXMJ83zG7uVogdMOHt0BRGhM+s0RFlNNUvPFG6P832yD8b2mD1qU= =2Vlj -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To post to this group, send email to Byzantium(a)hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe(a)hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To post to this group, send email to Byzantium(a)hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe(a)hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?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

[Mac_crypto] "Security Update 2002-08-02 for OpenSSL, Sun RPC,
by Fearghas McKay 06 Jul '18

06 Jul '18

mod_ssl" does not verify Sender: mac_crypto-admin(a)vmeng.com Date: Sat, 3 Aug 2002 08:38:50 +0100 **A verification of this security announcement mail fails** The key is signed by Vinnie Moscaritolo - vinnie(a)vmeng.com which is a good thing even if Vinnie is no longer at Apple ( which is a bad thing ), it is also signed by someone who does not appear on any of the public keyservers that I can find which is a bit disappointing. Verified version is at the bottom. f --- begin forwarded text

1 0

Security Update 2002-08-02 for OpenSSL, Sun RPC, mod_ssl
by Product Security 06 Jul '18

06 Jul '18

<security-announce.lists.apple.com> List-Post: <mailto:security-announce@lists.apple.com> List-Help: <mailto:security-announce-request@lists.apple.com?subject=help> List-Subscribe: <http://www.lists.apple.com/mailman/listinfo/security-announce>, <mailto:security-announce-request@lists.apple.com?subject=subscribe> List-Archive: <http://www.lists.apple.com/archives/security-announce/> Date: Fri, 2 Aug 2002 15:45:34 -0700 -----BEGIN PGP SIGNED MESSAGE----- Security Update 2002-08-02 is now available. It contains fixes for recent vulnerabilities in: OpenSSL: Fixes security vulnerabilities CAN-2002-0656, CAN-2002-0657, CAN-2002-0655, and CAN-2002-0659. Details are available via: http://www.cert.org/advisories/CA-2002-23.html mod_ssl: Fixes CAN-2002-0653, an off-by-one buffer overflow in the mod_ssl Apache module. Details are available via: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0653 Sun RPC: Fixes CAN-2002-039, a buffer overflow in the Sun RPC XDR decoder. Details are available via: http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20823 Affected systems: Mac OS X client and Mac OS X Server Note: Mac OS X client is configured by default to have these services turned off, and is only vulnerable if the user has enabled network services which rely on the affected components. It is still recommended for Mac OS X client users to apply this security update to their system. System requirements: Mac OS X 10.1.5 Security Update 2002-08-02 may be obtained from: * Software Update pane in System Preferences * Apple's Software Downloads web site: http://docs.info.apple.com/article.html?artnum=120139 SSL server: https://depot.info.apple.com/security/129403bc5e184e3b7367.html To help verify the integrity of Security Update 2002-08-02 from the Software Downloads web site: The download file is titled: SecurityUpd2002-08-02.dmg Its SHA-1 digest is: 54f6eebe0398181db8f1129403bc5e184e3b7367 Information will also be posted to the Apple Product Security web site: http://www.apple.com/support/security/security_updates.html This message is signed with Apple's Product Security PGP key, and details are available at: http://www.apple.com/support/security/security_pgp.html -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.3 iQEVAwUBPUsLOiFlYNdE6F9oAQGAigf+JV+lazuko1g4oZSNFTd2puXCtOGQ0M8c 2cZ/BdaEBA8jLGrPkhWuvmMwpN9z6G9chnN8s9EXiavcBG5e/ejtTo3ZHoOGP7bg 789zLQLK2JTB75nc0fNyx2CdfHlEIM00v8c2jXySLlnqF+kzwqVnjUL7i2O97Fk5 tWXLc2dWK2Nf2SUk0/yLgfjceZKEPCPXTpuKYuah/w9NwzL+LsbPcfXA/H1f4ngc vRPc2sn2HYu9IJw/BrMEsDlS8IWHf6ozXdZ9qaVCVRrZlsd9gSSmB2Jba4be/MRX FauTTepMF9+JfCkx+2wtpwWhBcXoJnjwIZXOXwbbRjqXHmzzgu8D/Q== =fdGO -----END PGP SIGNATURE----- _______________________________________________ security-announce mailing list | security-announce(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/security-announce Do not post admin requests to the list. They will be ignored. --- end forwarded text Verified version with verification failure ---

1 0

Security Update 2002-08-02 for OpenSSL, Sun RPC, mod_ssl
by Product Security 06 Jul '18

06 Jul '18

<security-announce.lists.apple.com> List-Post: <mailto:security-announce@lists.apple.com> List-Help: <mailto:security-announce-request@lists.apple.com?subject=help> List-Subscribe: <http://www.lists.apple.com/mailman/listinfo/security-announce>, <mailto:security-announce-request@lists.apple.com?subject=subscribe> List-Archive: <http://www.lists.apple.com/archives/security-announce/> Date: Fri, 2 Aug 2002 15:45:34 -0700 *** PGP SIGNATURE VERIFICATION *** *** Status: Bad Signature *** Alert: Signature did not verify. Message has been altered. *** Signer: Apple Product Security <product-security(a)apple.com> (0x44E85F68) *** Signed: 08/02/2002 11:44:10 PM *** Verified: 08/03/2002 08:34:01 AM *** BEGIN PGP VERIFIED MESSAGE *** Security Update 2002-08-02 is now available. It contains fixes for recent vulnerabilities in: OpenSSL: Fixes security vulnerabilities CAN-2002-0656, CAN-2002-0657, CAN-2002-0655, and CAN-2002-0659. Details are available via: http://www.cert.org/advisories/CA-2002-23.html mod_ssl: Fixes CAN-2002-0653, an off-by-one buffer overflow in the mod_ssl Apache module. Details are available via: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0653 Sun RPC: Fixes CAN-2002-039, a buffer overflow in the Sun RPC XDR decoder. Details are available via: http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20823 Affected systems: Mac OS X client and Mac OS X Server Note: Mac OS X client is configured by default to have these services turned off, and is only vulnerable if the user has enabled network services which rely on the affected components. It is still recommended for Mac OS X client users to apply this security update to their system. System requirements: Mac OS X 10.1.5 Security Update 2002-08-02 may be obtained from: * Software Update pane in System Preferences * Apple's Software Downloads web site: http://docs.info.apple.com/article.html?artnum=120139 SSL server: https://depot.info.apple.com/security/129403bc5e184e3b7367.html To help verify the integrity of Security Update 2002-08-02 from the Software Downloads web site: The download file is titled: SecurityUpd2002-08-02.dmg Its SHA-1 digest is: 54f6eebe0398181db8f1129403bc5e184e3b7367 Information will also be posted to the Apple Product Security web site: http://www.apple.com/support/security/security_updates.html This message is signed with Apple's Product Security PGP key, and details are available at: http://www.apple.com/support/security/security_pgp.html *** END PGP VERIFIED MESSAGE *** _______________________________________________ security-announce mailing list | security-announce(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/security-announce Do not post admin requests to the list. They will be ignored. --- _______________________________________________ mac_crypto mailing list mac_crypto(a)vmeng.com http://www.vmeng.com/mailman/listinfo/mac_crypto --- 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

None
by Tom 06 Jul '18

06 Jul '18

>"Roy M. Silvernail" wrote: >> >> A quote from http://www.thestandard.com/article/display/0,1151,20985,00.html: >> >> " Criminal organizations appear to be using the proceeds of >> IP-infringing products to facilitate a variety of enterprises, >> including guns, drugs, pornography and even terrorism. Invariably, >> when there is intellectual property crime, there is tax evasion and >> money laundering." >> >> Note that last sentence. > >she forgot to mention child abuse. Merely not mentioned in the Standard article. See: http://www.whitehouse.gov/WH/EOP/NSC/html/documents/pub45270/pub45270chap1.h tml#4

1 0