- cypherpunks - lists.cpunks.org

Cypherpunks archive description.
by jim bell 04 Nov '19

04 Nov '19

Cypherpunks Archive 1992-1998 John Young jya(a)pipeline.com Fri Sep 6 16:17:54 EDT 2013 - Previous message: Old list archives - Next message: [pfSense] [liberationtech] NSA Laughs at PCs, Prefers Hacking Routers and Switches - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Cypherpunks Archive 1992-1998 in raw text: http://cryptome.org/cpunks/cpunks-92-98.zip (83MB) By year: http://cryptome.org/cpunks/cpunks-1992.zip (790KB) http://cryptome.org/cpunks/cpunks-1993.zip (7.4MB) http://cryptome.org/cpunks/cpunks-1994.zip (11.8MB) http://cryptome.org/cpunks/cpunks-1995.zip (10.1MB) http://cryptome.org/cpunks/cpunks-1996.zip (21.6MB) http://cryptome.org/cpunks/cpunks-1997.zip (20.7MB) http://cryptome.org/cpunks/cpunks-1998.zip (10.8MB) Who October 26, 1996: http://cryptome.org/cpunks/cpnkwho-102296.txt (34KB) At 03:06 PM 9/6/2013, you wrote: >On Fri, Sep 06, 2013 at 12:13:50PM -0400, grarpamp wrote: > > On 9/6/13, CypherPunk <cypherpunk(a)cpunk.us> wrote: > > > On 09/06/2013 06:17 AM, John Preston wrote: > > >> I'm having trouble finding the list archives going back into the 90's; > > >> they're not on cpunks.org. Anyone got them? > > > > > > http://cypherpunks.venona.com/ > > > > cryptome has a partial zip archive you can search for. > > > > For those that use real MUA's/search with local copies > > instead of crippled web indexes further subject to disappearance, > > and to cover time gaps and provide a canonical answer > > to this recurring question.... > > > > I suggest people here collaborate and contribute to > > create a complete historical archive in mbox and/or maildir > >An excellent idea. Unfortunately, I lost my 1980s/90s >emails due to a shredded RAID. > > > format. Once compiled and deduplicated it could be > > broken out and presented by year in said formats and > > also loaded into mailman/pipermail. > > > > What datasets do you all have and in what formats? > > Can you upload and/or post links to them? > > > > I believe cpunks.org is willing to host such an archive. > >I will put up a mirror as well. mbox format is perfect. - Previous message: Old list archives - Next message: [pfSense] [liberationtech] NSA Laughs at PCs, Prefers Hacking Routers and Switches - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the cypherpunks mailing list

2 2

ScienceAlert: Scientists Have Made a Quantum Encryptor 1,000 Times Smaller Than What Came Before
by jim bell 04 Nov '19

04 Nov '19

ScienceAlert: Scientists Have Made a Quantum Encryptor 1,000 Times Smaller Than What Came Before. https://www.sciencealert.com/scientists-have-made-a-quantum-chip-that-s-1-0…

1 0

My comment on the Cypherpunks archive website, https://cryptoanarchy.wiki/blog/2018/07/05/the-cypherpunks-mailing-list-archives-must-be-preserved.html
by jim bell 04 Nov '19

04 Nov '19

https://cryptoanarchy.wiki/blog/2018/07/05/the-cypherpunks-mailing-list-arc… Four days ago, I began to discover the existence of a massive data-tampering fraud associated with the 1995 database of the Cypherpunks email list. There is a huge 4-5-month gap, beginning Feb 14, 2019, in which virtually no messages appear, probably missing many thousands of postings. This wasn't due to an innocent loss of data, either. Then, the messages dated both during and subsequent to July, 1995, virtually every instance of the text string "jim bell", "jimbell(a)pacifier.com", "AP" (when the text AP means "Assassination Politics"; and yet the few remaining instances of "ap" stand for "Associated Press" and in one case "killer ap" astonishingly remain), and "Assassination Politics" itself. For an archive where these gargantuan forgeries presumably (I hope!!!) don't exist, see the same archive for the year 1996.I, Jim Bell, had been posting extensively, perhaps beginning shortly after Feb 14, 1995, and fairly continuously at the CP list at least until early 1997. My Assassination Politics essay https://cryptome.org/ap.htm was heavily discussed during these times, and during and after 1997 as well. Any people who posted messages on that list, Cypherpunks, should have been listed, although their emails might subsequently have changed in the 24 years subsequent to that. And, of course, any messages either to or from me, from anyone, (at the time jimbell(a)pacifier.com, address no longer valid in 2019)Presumably, the current operator of the archive, Tom Busby, was fed intentionally false and carefully-forged data, a fraud which he must not have known about, and he dutifully turned it into the archive which now appears, unaware of the data sham that preceded his role. I am now requesting that anyone who has data for this period (1995) of the Cypherpunks email list first post it publicly in a location where it will be regularly scraped by the Internet's Wayback Machine https://archive.org/web/ , and post a citation to that data on the Cypherpunks list contemporaneous to its availability.

1 0

lightweight attestation/ signatures - GPG - minisign
by Zenaan Harkness 03 Nov '19

03 Nov '19

This one recent LWN.net article shares this one amazing secret to lightweight attestation digital signatures. Instead of a GPG sig block, which is rather fat 'n' frumpy in the face of a short email, minisign signatures look more like a git hash: untrusted comment: <arbitrary text> base64(<signature_algorithm> || <key_id> || <signature>) trusted_comment: <arbitrary text> base64(<global_signature>) - signature_algorithm: Ed - key_id: 8 random bytes, matching the public key - signature (PureEdDSA): ed25519(<file data>) - signature (HashedEdDSA): ed25519(Blake2b-512(<file data>)) - global_signature: ed25519(<signature> || <trusted_comment>) For emails, I'm guessing the untrusted and trusted comments (at least) would not be needed; needs more exploration. Another tool fer ya lolibag... Next steps for kernel workflow improvement https://lwn.net/Articles/803619/ ... His proposal is to introduce signatures on emailed patches as well. The mechanism used would be minisign, not GnuPG; one of the big advantages of minisign is that the attached signatures are much shorter than those created by GnuPG. Steve Rostedt interrupted at this point to question the value of this approach; he said that an attack, to be successful, would have to involve a relatively complex patch written in a style that mimics that of the purported author. It would be a big effort, he said; anybody with the resources to do that could also crack the encryption scheme used for attestation. ... https://jedisct1.github.io/minisign/ # Minisign Minisign is a dead simple tool to sign files and verify signatures. It is portable, lightweight, and uses the highly secure Ed25519 public-key signature system. ## Creating a key pair $ minisign -G The public key is printed and put into the minisign.pub file. The secret key is encrypted and saved as a file named ~/.minisign/minisign.key. ## Signing a file $ minisign -Sm myfile.txt Or to include a comment in the signature, that will be verified and displayed when verifying the file: $ minisign -Sm myfile.txt -t 'This comment will be signed as well' The signature is put into myfile.txt.minisig. Starting with version 0.8, multiple files can also be signed at once: $ minisign -Sm file1.txt file2.txt *.jpg ## Verifying a file $ minisign -Vm myfile.txt -P RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3 or $ minisign -Vm myfile.txt -p signature.pub This requires the signature myfile.txt.minisig to be present in the same directory. The public key can either reside in a file (./minisign.pub by default) or be directly specified on the command line. ...

1 0

Why Google's Quantum Victory Is a Huge Deal—and a Letdown
by jim bell 03 Nov '19

03 Nov '19

https://www.wired.com/story/why-googles-quantum-computing-victory-is-a-huge…

4 3

[PEACE] True story: Afghanistan's last remaining Jew kicked out of Taliban jail "for being too annoying"
by Zenaan Harkness 03 Nov '19

03 Nov '19

Some true stories "say waht?!" but yes, it's true, Afghanistan's (believed to be) last remaining Jew, Zabulon Simentov, was too annoying for the Taliban to keep jailed, so they kicked him out: Afghanistan’s Last Jews Were Freed From Prison Because They Were So Annoying https://forward.com/news/world/434041/afghanistan-jews-taliban/ ... Meet Zabulon Simentov, 66, who is believed to be the last remaining Jew in Afghanistan. Emran Feroz recently profiled Simentov for Foreign Policy and uncovered some incredible stories about the feisty Afghan — including that the Taliban once imprisoned him for arguing with a fellow Jew, then kicked him out because the constant bickering became too annoying. ... Found here: Finally, A Jewish News Headline I Can Believe http://dstormer6em3i4km.onion/finally-a-jewish-news-headline-i-can-believe/

1 0

[PEACE] - ABSOLUTE CRISIS - Climate on brink of CHANGING! - [PEACE]
by Zenaan Harkness 03 Nov '19

03 Nov '19

It's an absolute crisis folkd, the climate is right on the brink of changing - down under we're about to get all hot and steamy as the climate changes into Summer, and all you mad c##ts up North are about to experience an amazing annual climate change - Winter! Empress Greta "The Supinate Autiste" Thunderburger is on a mission to SAVE the world from climate change! To do this, she is is here to expose, willfully, climate change deniers by staring at them disapprovingly! Di Caprio and Thundberg are now travelling to the UN's climate hoaxes, sorry I mean climate conferences, in Di Caprio's private jet, since Thunberg got lost in Africa or somewhere on the globe... and started begging for $$ to get to the next hoax conference. In return, Thunberg is volunteering her gift to Di Caprio of "stare at people very disapprovingly to force them to donate money or something". Now THAT's climate co-operation: Greta Thunberg May or May Not be in Some Kind of Relationship with Leo DiCaprio http://dstormer6em3i4km.onion/greta-thunberg-may-or-may-not-be-in-some-kind…

1 0

RPI develops 3-D-printed living skin with blood vessels included
by Razer 03 Nov '19

03 Nov '19

Rensselaer Polytechnic Institute: "Researchers at Rensselaer Polytechnic Institute have developed a way to 3-D print living skin, complete with blood vessels. The advancement, published online today in Tissue Engineering Part A, is a significant step toward creating grafts that are more like the skin our bodies produce naturally. "Right now, whatever is available as a clinical product is more like a fancy Band-Aid," said Pankaj Karande, an associate professor of chemical and biological engineering and member of the Center for Biotechnology and Interdisciplinary Studies (CBIS), who led this research at Rensselaer. "It provides some accelerated wound healing, but eventually it just falls off; it never really integrates with the host cells." A significant barrier to that integration has been the absence of a functioning vascular system in the skin grafts. Karande has been working on this challenge for several years, previously publishing one of the first papers showing that researchers could take two types of living human cells, make them into "bio-inks," and print them into a skin-like structure. Since then, he and his team have been working with researchers from Yale School of Medicine to incorporate vasculature. In this paper, the researchers show that if they add key elements—including human endothelial cells, which line the inside of blood vessels, and human pericyte cells, which wrap around the endothelial cells—with animal collagen and other structural cells typically found in a skin graft, the cells start communicating and forming a biologically relevant vascular structure within the span of a few weeks. You can watch Karande explain this development here. "As engineers working to recreate biology, we've always appreciated and been aware of the fact that biology is far more complex than the simple systems we make in the lab," Karande said. "We were pleasantly surprised to find that, once we start approaching that complexity, biology takes over and starts getting closer and closer to what exists in nature." Once the Yale team grafted it onto a special type of mouse, the vessels from the skin printed by the Rensselaer team began to communicate and connect with the mouse's own vessels. "That's extremely important, because we know there is actually a transfer of blood and nutrients to the graft which is keeping the graft alive," Karande said. In order to make this usable at a clinical level, researchers need to be able to edit the donor cells using something like the CRISPR technology, so that the vessels can integrate and be accepted by the patient's body. "We are still not at that step, but we are one step closer," Karande said. "This significant development highlights the vast potential of 3-D bioprinting in precision medicine, where solutions can be tailored to specific situations and eventually to individuals," said Deepak Vashishth, the director CBIS. "This is a perfect example of how engineers at Rensselaer are solving challenges related to human health." Karande said more work will need to be done to address the challenges associated with burn patients, which include the loss of nerve and vascular endings. But the grafts his team has created bring researchers closer to helping people with more discrete issues, like diabetic or pressure ulcers. "For those patients, these would be perfect, because ulcers usually appear at distinct locations on the body and can be addressed with smaller pieces of skin," Karande said. "Wound healing typically takes longer in diabetic patients, and this could also help to accelerate that process." https://medicalxpress.com/news/2019-11-skin-d-printed-blood-vessels.html Rr Sent from my Androgyne dee-vice with K-9 Mail

1 0

Git falls - email keeps getting blocket - attempting from gmail web ui direct
by Zenaan Harkness 02 Nov '19

02 Nov '19

Ric, if you get this, please reply - my ISP kept giving me "Email ACCEPTED" and then sending it into a black hole it seems. Perhaps I used the word "sn0wfl4ke" too many times? cheers zen ----- Forwarded message from Zenaan Harkness <git-rev-news(a)freedbms.net> ----- From: Zenaan Harkness <git-rev-news(a)freedbms.net> To: CypherPunks <cypherpunks(a)lists.cpunks.org> Cc: wayward4now(a)gmail.com, andrewanglin84(a)gmail.com, rms(a)gnu.org, inspector_rikati(a)yahoo.com.au Date: Sun, 3 Nov 2019 10:15:18 +1100 Subject: Re: Git falls to the giant swinging CoCs! -- [gitrevnews(a)gmail.com: Git Rev News edition 56] Anyone know A Better Way for such emails as below? Email is broken in some ways it seems - the below email evidently had a few trip words or repetitions such that the ISP, despite its mail server saying to me "ACCEPTED" for each (of 5) recipient, has not sent the email through. No error, no warning, just "Email ACCEPTED" and then into a black hole! This is disappointing of course. And I guess if they (Telstra's SMTP server in this case) lower their SPAM scoring, then too much spam gets through and folks get annoyed - looks like this is a "broken" in email? Anyway, may be this one will similarly be black holed ... let's see... On Sun, Nov 03, 2019 at 09:50:16AM +1100, Zenaan Harkness wrote: > Those with limp and dodgy feelz, are inevitably compelled to seek > "safety" in numbers, introducing CoCs (code of conduct aka "community > stasi policing"), raging inflamed discussions, and censorship "safety > first" committees to make damnably sure their snow CoC is obeyed! > > Sadly, Git is the latest project to fall (see below). > > Perhaps we ought begin to consider anti-dotes to such snowflakery? > > > - separation of man and snowflake > > have the place (e.g. mailing list) for adults to get on with work > > have the snowflake hall, say snowflakes(a)$MY_PROJECT.$TLD > > > As we see recently with the FSF and Richard Stallman, those who > contribute over a long period of time, and have deceived the group by > successfully hiding their snowflakery and huge swinging CoC demands, > tend towards the public lynch mob, the coup, and the crucifixion of > good men, including the founder. > > > Such deception, where folks instead of finding or creating their own > space like a man, they simmer and seethe in anger, plotting their > evil for the day the leader takes a public hit from morons, are > deceivers and back stabbers, cowards of the first order. > > > - never surrender to terrorists > > name evil behaviour, and handle the evil behaviour first and > foremost, at all times, as the first evil, even in the face of > a lynch mob > > blackmail should be the first evil, the first "illegal" crime > punishable by severe punishments, even where the perpetrator of > the blackmail is a spook or deep CoC > > deception and hiding of snowflakery is a ground for dismissal - > sure, the flake might chuck an Amway retard programming spaz and > try to fuck over the group by "leave a big hole" (what do we > expect from CoCs anyway?) - but let's just be thankful for the > work they did do, and get on with being men - in the long run, > we'll be better off without that undermining shit! > > (for those who missed the memo, leave a big hole means "make my > pathetic self really valuable and then leave a huge hole in the > group by leaving" - well, men don't give a firetruck, we learn > the lesson of the CoC and move on, filling that hole, spoon by > bloody spoon if we have to!) > > > - always immediately (or as soon as possible) name a terrorist act > > e.g. > the Koch brothers come to your Think Pad Update Services > Association (TP-USA) offering "a million fiats for your CoC" > > make immediate public announcement "Koch brothers seek CoC, > attempt to corrupt men@list with limp fiats and demanding > censorship" > > e.g. > snowflake seeks to censor men@list with large swinging CoC, > even though snowflakes@list is offered and actively CoCing > around > > make public announcement "apparently snowflakes like CoC so > bad, they seek to ram CoC in face of men@list" > > > Yes, we should (probably, presumably, duty of care etc) > > - make an up front, open and honest declaration of intent for the > men@list list > > "are you a man or a f*#!& meme, if the former you may join the > primary list, if anything else, join the snowflakes and/ or seek > a mentor willing to personally tutor you; > if reading this message was overly stressful to your feelz, get > some firetrucking help already!" > > if your project is so fortunate as to have at least one > contributor who is willing to be on both the men@list list, and > the snowjobs@list, all the better - in fact there are plenty of > mediator types out there, so it's usually only a very short > matter of time before a White Knight steps up to vigorously seize > the CoC obeying kudos creds on the snowjobs list > > > Make such declarations so folks know what they're getting into from > the get go. > > After that, it's open season muffas :D > > "Oh PLEASE muh little snowflake, pleease step into the ring! > > Yes my precious, you know you wanna be a man, so join, don't > hesitate, join the list of men and leave your tissues outside. > " > > > Of course, if everyone, or everyone of any authority in a project, is > a censorship craving CoC nut, and you happen to be a man, or at least > a man in training, we suggest you join another project, or start yer > own, such as NoMoreAnalCommittees(a)for.men.only > > > Hopefully there are further decisive CoC-flake slaying ideas and > approaches out there - experiment and report back, so we can share > the winning to all men of good character and high ideals. > > > Peace, > > > > ----- Forwarded message from Git Rev News Team <gitrevnews(a)gmail.com> ----- > > From: Git Rev News Team <gitrevnews(a)gmail.com> > To: git-rev-news(a)freedbms.net > Date: Sat, 2 Nov 2019 19:38:22 +0000 > Subject: Git Rev News edition 56 > List-ID: 318f078aaef2e75d94c2bf757mc list <318f078aaef2e75d94c2bf757.118053.list-id.mcsv.net> > > > > View this email in your browser (https://mailchi.mp/5e0c777b9b30/git-rev-news-edition-56?e=2778fe651d) > > > ** Git Rev News: Edition 56 (October 26th, 2019) > ------------------------------------------------------------ > > Welcome to the 56th edition of Git Rev News (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) on git.github.io. > > This edition covers what happened during the month of September 2019. > > > ** Discussions > ------------------------------------------------------------ > > > ** General > ------------------------------------------------------------ > * Growing the Git community (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > Derrick Stolee, who prefers to be called Stolee, emailed the mailing list after the Virtual Contributor Summit (see previous edition (/rev_news/2019/09/25/edition-55/#general) ) saying he wanted to further discuss some ideas, that had been shared during the Summit, about “Inclusion & Diversity” with the goal of making the community more welcoming to new contributors of all kinds. > He listed some possible problems that could prevent new contributors entering the community: > 1. Discovering how to contribute to Git is non-obvious. > 2. Submitting to a mailing list is a new experience for most developers. This includes the full review and discussion process. > 3. The high standards for patch quality are intimidating to new contributors. > 4. Some people do not feel comfortable engaging in a community without a clear Code of Conduct. This discomfort is significant and based on real experiences throughout society. > 5. Since Git development happens in a different place than where users acquire the end product, some are not aware that they can contribute. > Then Stolee proposed actions to address the problems: > 1. Improve the documentation for contributing to Git. > 2. Add more pointers to GitGitGadget. > 3. Introduce a new “mentors” mailing list. > 4. Add an official Code of Conduct. > 5. Advertise that Git wants new contributors. > Each action was explained and justified, sometimes pointing to interesting research like the recent paper "”We Don’t Do That Here”: How Collaborative Editing With Mentors Improves Engagement in Social Q&A Communities” (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) . > Stolee also proposed some metrics to be measured between releases to monitor how the community are doing: > 1. How many first-time contributors sent a patch? > 2. How many contributors had their first commit accepted into the release? > 3. How many contributors started reviewing? > 4. How many total patches/reviews did the list receive? > His email was very detailed with many suggestions about how to implement the actions, and he asked interesting questions to gather peoples’ opinion. > Denton Liu replied to Stolee sharing some thoughts as a “relatively new contributor (just less than a year)”. He said that from his experience to get more contributors, we should try to answer the “how do we make it more fun to contribute to Git?” question. > He recalled that most of his time learning to contribute to Git “stemmed from the fact that there’s a lot of tribal knowledge that’s not really written down anywhere”. > As Stolee had mentioned the “My First Contribution” document (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , which was recently contributed by Emily Shaffer, Denton said that it would have really helped him get started. > Denton also suggested improving transparency about what happens to patches sent to the mailing list. > Mike Hommey replied to Stolee suggesting an additional problem which is that newcomers don’t really have any idea what they could contribute. > Johannes Schindelin, alias Dscho, replied to Mike that newcomers need experienced developers to validate the ideas they would like to implement in Git, before they can be confident enough to work on them. And they also need to be shown ideas they could implement. Dscho then talked about the GitGitGadget issue list (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) which is open and “intended to accumulate possible project ideas”. Dscho also acknowledged the Chromium Git issue list (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) which is another issue tracker with a similar purpose. > Replying to Stolee, Jeff King, alias Peff, who is responsible for the main Git web site (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , suggested improving the community page (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) to add more information for beginners. He said he was open to accepting patches or pull requests (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) . > Elijah Newren mostly agreed with Stolee’s email, but suggested a less strongly worded tone when talking about goals and existing problems. > Junio Hamano, the Git maintainer, replied to Stolee about the goal of the project and the metrics that we could use with the following: > > We first should make sure that we serve existing users and existing community members well. So well that other people who are not yet our “existing” users and members would want to become part of us, in order to join the fun and share the benefit. If we cannot serve even the existing members well, we shouldn’t be talking about acquiring new members. > He then proposed to measure “community-member happiness” with metrics like “This many percent of total community member population have been active this month”. > The discussion involved a number of other Git developers like Jakub Narębski, Emily Shaffer, Garima Singh, Pierre Tardy, Philip Oakley and Randall S. Becker. > A number of people commented especially on the subject of adding an official Code of Conduct, which will be reported on in a separate article below. > Otherwise it remains to be seen if many actions will be taken to make the project more welcoming to new contributors. > * [PATCH] add a Code of Conduct document (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > Following the Virtual Contributor Summit (see previous edition (/rev_news/2019/09/25/edition-55/#general) ) and the discussions about growing the Git community (see the article above), Jeff King, alias Peff, decided to send a patch to add a code of conduct. > In his patch he says that “it may be a good time to cement our expectations when things are quiet, since it gives everybody some distance rather than focusing on a current contentious issue”. Many people indeed agreed in the previous discussions with that point of view, and the idea of a Code of Conduct in the first place. > Peff says that his patch adapts the Contributor Covenant Code of Conduct from https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757… and that “it’s also the same document used by the Git for Windows project”. > One of the changes is that for dealing with community issues, the document spreads the responsibility to the Project Leadership Committee (git(a)sfconservancy.org) instead of the only maintainer, Junio C Hamano. > Peff also mentioned a commit (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by Michael Haggerty from June 2013 that he found in a previous discussion and that has nice set of guidelines about how to review code. > A number of the replies were about the Project Leadership Committee as it’s not easy to know who is part of it. This was acknowledged by Peff who sent a follow-up patch (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) to address the issue by listing the Project Leadership Committee members with their email addresses and by saying that they can also be contacted individually. > Even though there was some disagreement, in general most of the people taking part in the discussion agreed with Peff’s patches. Junio later sent a follow-up email (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) with the subject “Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks” to get more developers to formally agree with the final patch, which then several did. > The commit adding the Code of Conduct has since been merged into the master branch. > > > ** Releases > ------------------------------------------------------------ > * Git 2.24.0-rc0 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > * Git for Windows 2.24.0-rc0 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > * GitHub Enterprise 2.18.4 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.17.10 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.16.19 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.15.24 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.18.3 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.17.9 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.16.18 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.15.23 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > * GitLab 12.4 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 12.3.5, 12.2.8, and 12.1.14 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 12.3.4 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 12.3.3, 12.2.7, and 12.1.13 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 12.3.2, 12.2.6, and 12.1.12 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 12.3.1 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 12.3 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > * Bitbucket Server 6.7 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > * Gerrit Code Review 3.0.3 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > * GitKraken 6.3.0 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 6.2.1 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > * GitHub Desktop 2.2.1 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) , 2.2.0 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) > > > ** Other News > ------------------------------------------------------------ > > Various > * A new maintainer for Git-Gui, Pratyush Yadav (@prati0100), came forward (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) . Let’s praise and thank him for volunteering. > * The Gerrit User Summit 2019 is going to be broadcasted on live.gerritforge.com (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) and will include talks about JGit and Gerrit Code Review, including major members of the Git Community, like Jonathan Nieder and Terry Parker. > > Light reading > * Commit graph drawing algorithms (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by pvigier (Pierre Vigier), describes algorithms used by various tools including one in pvigier’s prototype git client called gitamine (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) . > * Git Pathspecs and How to Use Them (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by Adam Giese. > * GitHub Actions, the missing notes: CMake, Qt and IFW (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by Michele ‘skypjack’ Caini, shows how he uses GitHub Actions (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) in his project. (GitHub Actions, still in public beta, were first covered in Git Rev News #44 (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) ) > * An Unintentionally Comprehensive Introduction to GitHub Actions CI (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by Tierney Cyren – with example of an application build on top of Node.js. > * Scheduling Jekyll posts with Netlify and GitHub Actions (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by Nicholas C. Zakas on his Human Who Codes blog: using a GitHub Action cron job to schedule Netlify builds for static site generated blog posts (which was previously done using Netlify and AWS Lambda (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) ). > * “git request-pull” and confusing diffstats [LWN.net] (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by Jonathan Corbet talks about what to do if the history to be pulled includes merges from outside (e.g. to obtain the dependencies for a fix), and why it happens. > * How Bash completion works (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) and Adding Bash completion to my tool (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) by Chris Patuzzo; Git’s Bash completion can be found in contrib/completion/git-completion.bash (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) . > > Git tools and sites > * Gollum (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) is a simple, Git-powered wiki written in Ruby with a sweet API and local frontend. > * git_examples.sh (https://github.us10.list-manage.com/track/click?u=318f078aaef2e75d94c2bf757…) – 99% of the Git commands you’ll need at work, demonstrated in a single script. > > > ** Credits > ------------------------------------------------------------ > > This edition of Git Rev News was curated by Christian Couder , Jakub Narębski , Markus Jansen and Gabriel Alcaras with help from Emily Shaffer, Luca Milanesio and George Espinoza. > > ============================================================ > You are receiving this email because you signed up to receive the Git Rev News newsletter. > > Our mailing address is: > Software Freedom Conservancy - Git Project > 137 Montague ST STE 380 > New York, NY 11201 > USA > ** unsubscribe from this list (https://github.us10.list-manage.com/unsubscribe?u=318f078aaef2e75d94c2bf757…) > ** update subscription preferences (https://github.us10.list-manage.com/profile?u=318f078aaef2e75d94c2bf757&id=…) > Email Marketing Powered by Mailchimp > http://www.mailchimp.com/monkey-rewards/?utm_source=freemium_newsletter&utm… > > ----- End forwarded message ----- ----- End forwarded message -----

1 0

How a months-old AMD microcode bug destroyed my weekend [UPDATED]
by coderman 02 Nov '19

02 Nov '19

[Stylized image of spiders creeping across screen covered with code.][Enlarge](https://cdn.arstechnica.net/wp-content/uploads/2019/10/bugs… / Ryzen 3000's RDRAND function—what should be a high-quality pseudo-random number generator—just returns 0xFFFFFFFFF every time, until its microcode is patched. This weekend, I was excited to deploy my first Ryzen 3000-powered workstation in my home office. Unfortunately, a microcode bug—originally discovered in July but still floating around in large numbers in the wild—wrecked my good time. I eventually got my Ryzen 3700X system working, and it's definitely fast. But unfortunately, it's still bugged, and there's no easy way to fix it. Not long after the product launch, AMD Ryzen 3000 customers started noticing problems with their shiny new CPUs. Windows users couldn't successfully launch Destiny 2 (due to a power-management bug, unrelated to the one sidelining my system), and Linux users in many cases couldn't even get their system to boot. Jason Evangelho [covered](https://www.forbes.com/sites/jasonevangelho/2019/07/12/amd-motherb… the initial discovery and report of the bug at Forbes back in July, and an AMD representative provided him with a statement by email: > AMD has identified the root cause and implemented a BIOS fix for an issue impacting the ability to run certain Linux distributions and Destiny 2 on Ryzen 3000 processors. We have distributed an updated BIOS to our motherboard partners, and we expect consumers to have access to the new BIOS over the coming days. This sounds happy and upbeat, but the reality isn't quite so simple. When there's a bug in the CPU microcode, you're at the mercy of your motherboard vendor to release a new system BIOS that will update it for you—you can't just go to some download link at AMD and apply a fix yourself. AMD responded to the bug in July. As far as I can tell, AMD did so only by direct email response; there's no press release about it—and the company's response made it sound like everything would be fixed in a week or two. I have the unfortunate duty of reporting to you, three months later, that it is not. What’s an RDRAND? The microcode bug in question is a faulty response to the RDRAND instruction. Modern x86_64 CPUs—beginning with Intel's Broadwell and AMD's Zen architectures—are supposed to have high-quality onboard random number generators (RNGs), which use thermal "noise" to very rapidly offer high-entropy pseudorandom numbers to anybody with kernel-level access who wants it. [RDRAND](https://en.wikipedia.org/wiki/RdRand) is, in turn, the instruction that provides these random numbers. All of this is supposed to be fairly failsafe. There's a CPUID function call that checks for the availability of RDRAND, and there's also a "carry bit" in the return value from a call to RDRAND that's supposed to let the calling application know if the CPU's RNG was unable to generate a sufficiently random number. Unfortunately, unpatched Ryzen 3000 says "yes" to the CPUID 01H call, sets the carry bit indicating it has successfully created the most artisanal, organic high-quality random number possible... and gives you a 0xFFFFFFFF for the "random" number, every single time. Obvious RDRAND bug impacts When the RDRAND bug in Ryzen 3000 first surfaced back in June, Linux users widely reported that their entire Ryzen 3000-powered systems wouldn't boot. The failure to boot was due to systemd's use of RDRAND—and it wasn't systemd's first clash with AMD and a buggy random-number generator, unfortunately. A much earlier bug in older CPUs caused some AMD systems to stop generating properly "random" numbers after resuming from suspend. The new bug caused Ryzen 3000 users to never get any proper random numbers at all. Both problems caused lockups in Linux operating systems using systemd, so in May systemd committed a [patch](https://github.com/systemd/systemd/commit/b62bc66018fa1ada09554e7ee4… that falls back to using alternate RNG sources if systemd receives the characteristic 0xFFFFFFFF back from the RNG. (This kinda sucks, because 0xFFFFFFFF is technically a perfectly valid random number—the implication here is that, after a sufficient length of time, systemd will decide any system has a buggy RNG when it eventually receives the "bad" number, even if it has never seen that number before.) Systemd's patch is ugly, but it certainly works well enough to allow systems to boot. Unfortunately, it doesn't fix the actual problem, which is that the CPU's random number generator is no more "random" than a two-headed penny. On my own system, I spent my entire weekend chasing phantom problems, first suspecting the system's brand-new RX 590 graphics card and (necessarily) updating distro and kernel versions before haring off from there. [My shiny new system kept barfing these nasty BUG: soft lockup<br /> —PU#n stuck for 22s errors, which would rapidly lock the whole system up. This call trace from /var/log/syslog didn't tell me the actual problem, but it was the first clue.](https://cdn.arstechnica.net/wp-content/uploads/2019/10/calltrace.png… / My shiny new system kept barfing these nasty BUG: soft lockup —PU#n stuck for 22s errors, which would rapidly lock the whole system up. This call trace from /var/log/syslog didn't tell me the actual problem, but it was the first clue. Jim Salter Eventually, after many false trails and much swearing, coffee, and less-respectable beverages, I actually read the call trace from my frequent CPU lockups—and "WireGuard" was right there, in every one of them. As it turns out, WireGuard relies on RDRAND (when available) to generate new session IDs. The session IDs need to be unique, and WireGuard wants them not to be simple consecutive integers, so it pulls a pseudorandom value from RDRAND, compares it against its existing session ID list to make sure there's no collision, then assigns it to the session. Read that last part again carefully—it makes sure there's no collision first. If an existing session has the same ID as the new number, WireGuard asks RDRAND for another "random" number, checks it for uniqueness, and so on. Since RDRAND on my system—and any non-microcode-updated Ryzen 3000 system—always returned 0xFFFFFFFF no matter what, that means infinite loop. Infinite loops in kernel code are bad; they introduce you to the value of the hardware reset button in a hurry. I want to be very clear here, this is not a WireGuard bug! WireGuard correctly checks to see if RDRAND is available, fetches a value if it is, and correctly checks to see if the carry bit is set. Then it indicates that, not only is there a value, it's a properly random one. Nevertheless, it's a problem that will lock up affected systems hard. A modern system needs high-quality pseudo-random numbers for lots of tasks, and the security implications of "random" meaning "always return0xFFFFFFFF" are difficult to predict. One obvious candidate is Address Space Layout Randomization (ASLR). Both [Windows](http://blog.ptsecurity.com/2012/12/windows-8-aslr-internals.html) and [Linux](https://lwn.net/Articles/569635/) use RDRAND as at least part of the randomness used to make sure code is never loaded in the same order twice, which mitigates against [stack-smashing](https://en.wikipedia.org/wiki/Stack_buffer_overflow) attacks. Fixing the problem—or at least recognizing it As AMD's representatives told reporters back in July, the real fix comes from applying BIOS updates to your motherboard and hoping that the BIOS update also includes the microcode patch for the CPU itself. When I checked my own BIOS using the dmidecode utility, I saw a date of August 12, 2019. But when I looked at Asus' download page for my motherboard, I saw downloads dated in September! Hurray! So I downloaded the BIOS update, saved it to a FAT32 thumb drive, rebooted my system, and went into setup. Unfortunately, after successfully applying the update and rebooting again, I realized my error—yes, Asus showed a later date for the BIOS, but the actual version was the same as the one I already had—3.2.0. My CPU still thought 0xFFFFFFFF was the randomest number ever, always, no matter what. At this point, I began to get paranoid—systemd had already quietly worked around the bug. But with most applications just quietly ignoring the problem, how would I know if it ever had been patched? What if two years later, I was still vulnerable to stack-smashing that I shouldn't have been, due to ASLR that wasn't actually randomizing? I discovered that I could use the linux utility hexdump against the kernel device /dev/hwrng to demonstrate that I had the problem. Unfortunately, the WireGuard project's Jason Donenfeld warned me that /dev/hwrng could, on some systems, derive its randomness from other sources—so while seeing a bunch of FF from it demonstrates that you have the problem, seeing valid pseudorandom data doesn't necessarily demonstrate that you don't. So he generously whipped up a couple of test utilities for the purpose that safely access RDRAND directly. If you're a Linux user, you can download [rdrand-test.zip](https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdr…, unzip it, and run it directly in the folder that you unzipped it in. ./amd-rdrandbug will tell you in plain English whether you have this specific bug, and ./test-rdrand will output 20 test RDRAND fetches. So you can confirm for yourself that you're not vulnerable to similar bugs either—if running ./test-rdrand produces the same set of values every time, it doesn't really matter whether they "look random," your RNG is broken! If you're a Windows user, you have a little more work ahead of you. First, [download](https://ubuntu.com/download/desktop) an Ubuntu desktop installer, then create an Ubuntu installer thumb drive. Then you can boot into the Ubuntu thumb drive's live environment (click "Try Ubuntu") and download and run the tests from there: you@ubuntu-live:~$ wget https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-test.zip you@ubuntu-live:~$ unzip rdrand-test.zip you@ubuntu-live:~$ cd rdrand-test you@ubuntu-live:~$ ./amd-rdrand.bug [In a sufficiently broad dataset, 20 consecutive 0xFFFFFFFF returns might be considered a valid "random" grouping. This is not a sufficiently broad dataset.](https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-fai… / In a sufficiently broad dataset, 20 consecutive 0xFFFFFFFF returns might be considered a valid "random" grouping. This is not a sufficiently broad dataset. Jim Salter Conclusions A broken random-number generator is a very serious bug, and it's troubling that more hasn't been said or done about this issue by AMD in the last three months. Ryzen 3000 is a great CPU platform in general, and I've been very impressed with the new system... except for spending an entire frustrated weekend troubleshooting it, being uneasy about the impact this will have on my overall system security, and having no idea when I can expect to be able to actually fix it. I reached out to AMD representatives earlier today, and they've responded with questions about my hardware but no solutions yet. I'll update this article with any fixes or recommendations as they arrive. Update: When I reached out to AMD for comment, a representative inquired about the make and model of my motherboard (Asrock Rack X470D4U) and the representative reached out in turn to Asrock. Asrock's team offered a custom BIOS available with the appropriate microcode fix; I respectfully declined to flash a one-off BIOS for me and me only, but the better news is that Asrock told AMD that the BIOS update should be publicly available in mid-November. (It is worth noting that some motherboards do already have BIOS updates available which do include the microcode fixes. Why the Asrock Rack X470D4U wasn't one of them is anybody's guess.) Readers in comments have suggested workarounds and mitigations in the meantime. The first was to pass nordrand as an argument to GRUB when booting. That doesn't fix the issue; it tells the kernel not to use the RDRAND instruction, but that doesn't have any impact on the advertised availability of the instruction in general. It's still exposed to the system, and any code that checks for the availability of RDRAND via CPUID is still going to see it there, and will still be able to use it directly. This is also the case with the similar random.trust_cpu Linux boot option. Neither of these workarounds actually disables RDRAND, so neither actually fixes the issue. Readers also suggested that if the amd64-microcode package were installed, it would fix the issue. This, too, is not the case; the amd64-microcode and intel-microcode packages are both installed by default on all Ubuntu 19.10 systems, including the one I'm experiencing the RDRAND failure on. I contacted AMD and asked representatives to check the status of that package and see if anything needs to (or can) be done about updating it. https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-…

5 6