04:25 <w00tSpeaks> Hi. I noticed that the behavior of openocd when detaching doesn't continue the program before exiting like it is supposed to. Where is the best place to file a bug. I am not clear from the website.

04:26 <Hawk777> Is that even a bug? I thought it left the target in its prior state on exit, intentionally (though maybe it not used to), but I thought it was also customizable with an event handler.

04:27 <w00tSpeaks> Detaching is supposed to continue execution vs quit which doesn't change the exec state.

04:28 <w00tSpeaks> From the help for detach: If a process, it is no longer traced, and it continues its execution.

04:28 <Hawk777> Is that from the GDB help for the GDB detach command?

04:28 <w00tSpeaks> yes. There are other docs that indicate the same.

04:29 <Hawk777> Hmmm, one could argue that a device connected via OpenOCD is not “a process” and therefore exempt from that rule, but I don’t know.

04:29 <Hawk777> Anyway, if you want to file a bug there’s a bug tracker link right on the front page of the website.

04:29 <w00tSpeaks> https://sourceware.org/gdb/onlinedocs/gdb/Attach.html

04:29 <Hawk777> I’m not saying it’s supposed to behave either way; I honestly don’t know.

04:30 <w00tSpeaks> Is there some place other than the gerrit to submit a patch? I see that it is not secured. I can't clone the repo from there of https or ssh.

04:30 <Hawk777> That said, it looks like the behaviour was discussed here <openocd.zylin.com/5600/> and left as no-resume intentionally.

04:31 <urja> I'm feeling like if you fix it now, you'll break someones workflow/expectations ... also i dunno it might be adapter/target specific too

04:47 <w00tSpeaks> disconnect just disconnects without detaching

05:05 <w00tSpeaks> urja: I hear that. But I'm wondering if we could have a config if that is a concern.

05:06 <w00tSpeaks> If patches are only taken via gerrit, how does one submit a patch securely?

05:06 <w00tSpeaks> I also have a config for a new board that I'd like to contribute.

05:18 <Hawk777> If you’re concerned about Gerrit’s security, I suppose you could sign your commits?

05:18 <Hawk777> Though they will be rebased (and therefore de-signed) when added to master.

05:21 <Hawk777> Which means if you really care a lot about security, you finding a secure way to send a patch to the OpenOCD maintainers will not really accomplish anything, given that an MITM between an OpenOCD maintainer and Gerrit (showing them something different than what will actually be committed) already provides a hole for malicious code to be added to the repo.

05:21 <Hawk777> So you might as well just use Gerrit.

05:30 <w00tSpeaks> I am concerned about doing anything over on a website without TLS.

05:31 <w00tSpeaks> I guess I can just submit a patch in a ticket on sf, which I haven't used in years.

05:33 <w00tSpeaks> Even sf.net uses Let's Encrypt certs.

05:33 <Hawk777> You’ll probably just get asked to send it to Gerrit instead.

05:33 <Hawk777> But I suppose you can try.

06:36 <PaulFertser> w00tSpeaks: when you push to Gerrit you do it over ssh

06:36 <PaulFertser> w00tSpeaks: what's not secure about it?

06:37 <PaulFertser> w00tSpeaks: https for review is in the works but what does it really help? Your communication with Gerrit when sending or getting patches is going over an e2e ssh channel, so what the concern is?

06:40 <Hawk777> I suppose if a reviewer reviews a patch over HTTP, they could approve it even though what they see is not what’s really in the patch.

06:40 <Hawk777> But that doesn’t affect submitters, only reviewers.

06:41 <Hawk777> Or they could just have their session stolen and used to approve malicious patches. But again, doesn’t affect submitters, only reviewers.

06:41 <PaulFertser> Hawk777: right.

06:42 <PaulFertser> But the mailing list will see the patch unaltered.

06:44 <Hawk777> True… not that SMTP is much better.

06:56 <PaulFertser> Hawk777: I do not think most mail providers accept mail unencrypted.

06:59 <Hawk777> Most probably offer opportunistic encryption; however, my understanding was that most senders, knowing that not *all* recipients support encryption, still allow sending unencrypted if STARTTLS is not offered as a capability by the recipient. Also, I was under the impression that certificate validation for SMTP was not very good (if done at all), because the certificate offered was generally for the mailserver hostname, not the envel

06:59 <Hawk777> domain name, further requiring MX validation via DNSSEC, which is also not deployed everywhere yet.

06:59 <Hawk777> So, lots of holes, though things *can* be non-terrible.

07:00 <Hawk777> Anyway, I personally don’t see it as a big deal for OpenOCD.

07:01 <PaulFertser> There's also SPF

07:02 <boru> So, why not just use PGP to sign the patches? Not sure what TLS delivers here, really. Surely all you want to know is that the patches came from who they say they came from.

07:03 <boru> Then you can just send that plain text over TLS or unencrypted links alike.

07:06 <Hawk777> Well, at that point you’re back to just doing signed git commits.

07:06 <Hawk777> Which is reasonable, if the reviewer doesn’t rely on Gerrit.

07:07 <boru> I have probably missed some context here, since I haven't read the entire scrollback, but that doesn't affect sending patches to the ML.

07:08 <boru> That said, I don't really have much experience with gerrit, either.

07:14 <PaulFertser> boru: the idea is that w00tSpeaks is hesitating sending his or her board support config and probably other patches to Gerrit because its web interface is plain http.

07:16 <boru> Can gerrit eat PGP signed text? Or does it require raw git patches or something?

07:16 <boru> The former being patch + appended signature.

07:16 <boru> As in plaintext.

07:18 <boru> On many, if not most, FOSS projects, you'll find the main contributors making use of PGP for this purpose. You can't control MTAs all the way to every client, so PGP will at least verify that the patches are coming from the person who posted them, regardless of the security of the link.

07:19 <boru> TLS is nice, but I'm not sure what the problem is with people being able to see patches you're contributing to a FOSS project...

07:19 <PaulFertser> boru: gerrit is accessed with git over ssh.

07:20 <Haohmaru> boru hiding from $boss?

07:20 <boru> Well, what's the problem with the web interface, then?

07:22 <PaulFertser> boru: I assumed there is supposed to be some MITM attack so that the patch is amended along the way, so what w00tSpeaks submits would be changed in nefarious ways. Or MITM on Gerrit maintainers to show them a "good" patch for some "bad" patch submitted on purpose so that the maintainers would be thinking they approve one content when in fact something else would be merged.

07:23 <boru> I'm very well aware of the risks of not using TLS. What I am advocating is signing patches which essentially makes the problem moot.

07:23 <boru> Which is why I asked if gerrit can accept signed patches.

07:23 <boru> Signed patches, or just text, whatever, could be sent over HTTP.

07:24 <PaulFertser> boru: what should the maintainers do with the signatures? And if someone connected over ssh to send a patch then the authentication phase is already performed, the person proved the posession of the corresponding private ssh key, right?

07:25 <PaulFertser> boru: signed patches will make cherry-picking odd, right? The maintainers will have to assume the ownership and re-sign in this case?

07:26 <boru> I just asked if gerrit's web interface can accept signed patches, or whatever this other user is trying to submit through the web interface.

07:26 <PaulFertser> boru: the web interface doesn't accept patcehs at all

07:27 <boru> How is this board configuration being submitted, then?

07:27 <PaulFertser> boru: via ssh to gerrit server

07:27 <boru> Further back you mentioned it was via a web interface over HTTP.

07:27 <boru> So I'm confused, now.

07:28 <boru> IIUC, the problem is not submitting patches, but reviewing them via HTTP?

07:28 <PaulFertser> boru: patch review process happens over HTTP currently, yes. Patch submission is over ssh. w00tSpeaks complained about the HTTP part but in the context of patch submission.

07:28 <boru> Okay, I understand now.

07:28 <PaulFertser> So the w00tSpeaks point is confusing :)

07:29 <boru> I read you wrong, sorry.

07:29 <PaulFertser> But we took the opportunity to discuss all related issues and random thoughts.

07:29 <PaulFertser> For the reference, Gerrit has a facility to additionally validate GPG signatures in submissions: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#receive.enableSignedPush

07:29 <boru> Then I would agree that TLS is probably sensible to deploy and serve over HTTPS only.

07:30 <boru> Yeah, that would be useful if someone is submitting a patch on someone else's behalf.

07:30 <PaulFertser> And I think normal GPG signatures in commits are also accepted, but the problem is when you press "Submit" Gerrit by default adds the review URL to the commit message so the signature won't be valid.

07:31 <boru> That's a bit annoying.

07:33 <PaulFertser> boru: would you prefer to annoy the contributors so that even if patch can be cleanly cherry-picked they would still need to resend on top of current master so that the signature would be valid. And that when you later look at git log you'd see no list of reviewers who approved it and no link to see the discussion?

07:37 <boru> Well, seeing as you have a commit hash, that is your breadcrumb to go and find those things on your $git_web_thing to find the MR or equivalent with relevant discussion or review comments.

07:38 <boru> I don't really see the utility of having that information in two places, personally.

07:39 <PaulFertser> boru: the commit hash will change to incorporate reviewers S-o-b

07:39 <boru> IME, signatures needn't be evaluated by your $git_web_thing either; I've worked on projects and in places where there were "trusted" mergemasters whose job would be to pgp verify and push to master. In which case, you can put whatever you want in the commit message.

07:40 <PaulFertser> And what would be the verification in case of a project accepting public contributions?

07:41 <boru> I think our requirements differ a bit, maybe. And as I said, I have practically no experience working with gerrit in anger.

07:41 <boru> The verification would be people with commit access for master verify the patches.

07:41 <PaulFertser> But it's not about Gerrit really, it's about a Git workflow. Gerrit is just a convenience tool on top of it.

07:44 <PaulFertser> So I have commit access for master, what am I supposed to do with the signature from a random person?

07:44 <boru> But you just said you want some sort of trail to the discussion and or reviews. Where do those live?

07:45 <boru> You verify it to determine it came from them. What else would you do with it?

07:45 <PaulFertser> boru: in case of Gerrit they live in its database. In case of patchwork, the patchwork instance.

07:45 <boru> That is the point of what I am suggesting.

07:46 <boru> Right, so therefore it _is_ about gerrit, in this case, and not just the workflow. Gerrit is an integral part of your workflow.

07:46 <PaulFertser> boru: so some random person submits a patch, do I need to verify that the GPG key was signed by me or my direct peers or what?

07:46 <PaulFertser> I think it'd work the same with Patchwork.

07:46 <boru> Point being that $git_web_thing is part of you workflow. Better?

07:47 <PaulFertser> It currently is, right.

07:47 <PaulFertser> But I do not think it is the reason for GPG-signed commits to be useless for a project like OpenOCD.

07:47 <boru> I am beginning to regret getting involved in this discussion. Feel free to disregard anthing I've suggested.

07:47 <boru> I have a lot of work to do today.

07:48 <PaulFertser> Thank you boru , please take no offense.

07:49 <boru> Don't worry, I'm not offended. I just wasn't expecting a protracted discussion. It was merely a suggestion, but I misunderstood the problem at the beginning anyway.

07:49 <PaulFertser> Sometimes discussions like that really help.

07:50 <boru> Well, I am missing a lot of context about how you (and the other contributors) prefer to work, so that doesn't really help, either.

07:51 <boru> It's something I will probably have to encounter again soon, since I have a bunch of things sitting in a fork which I'd like to push upstream at some point. Mostly riscv stuff.

07:51 <boru> When I have the time™...

07:51 <PaulFertser> Feel free to ask for details.

07:51 <PaulFertser> You can also consider sending them to riscv fork, and probably Tim will eventually take care of submitting everything needed upstream.

07:52 <boru> You pointed me to some documentation a while ago.

07:52 <boru> I'd rather not -- the riscv fork is a bit of a mess.

07:52 <boru> I had a look at some of their implementation for a particular device, and I thought it would be better just to write something from scratch...

07:53 <PaulFertser> Oh, I wasn't aware.

07:54 <boru> My fork is based off current upstream, and nothing has really changed other than support for a few devices. The existing JTAG implementation works fine with it, so a riscv fork seems very unnecessary to me anyway.

07:54 <PaulFertser> Good to know. I'm ready to answer specific questions about the submission procedure. It should be reasonably painless.

07:55 <boru> Once I get back to tidying up what I've got and making sure it's format compliant etc, I'll get back to you.

07:57 <PaulFertser> Thank you!

09:30 <PaulFertser> As if you waste less time reading ##stm32 scrollbacks.

09:33 <Haohmaru> aww

09:44 <karlp> stm32 stuff is normally more rational

09:45 <boru> Okay, I'll bite. Which part do you think was irrational?

09:46 <PaulFertser> It probably sounded like a typical discussion on a TV show, everybody talked about their own mildly related topic :)

09:53 <karlp> boru: I won't

09:54 <Haohmaru> did that channel move to here?

09:55 <Haohmaru> or did it stay on freenope

09:55 <PaulFertser> Haohmaru: freenode doesn't allow anonymous IRC connections anymore

09:56 <boru> Thought as much.

09:56 <boru> I think SASL is forced, which means you must identify before connecting to freenode.

09:56 <boru> For "security".

09:57 <Haohmaru> i heard that

09:58 <boru> Ergo, you must be registered. Makes it a bit annoying if you want to report a bug or ask for help.

09:58 <Haohmaru> annoying? who would even wanna use freenope?!

09:59 <boru> GCC would be in the same boat if OFTC forced registration, since their development channel is there.

10:00 <Haohmaru> i assume OFTC is run by.. sane humans

10:00 <Haohmaru> altho i heard they do have some weird requirement

10:01 <Haohmaru> don't tell me redi is still on freenope :/

10:01 <boru> I doubt it.

10:01 <boru> All of the binutils people have moved, I think.

10:01 <boru> And most of the GCC people never moved from OFTC to begin with.

10:05 <Haohmaru> yeah, sure.. the official channels have been there all the time

19:55 <Fleck> is that common thing, if I want to transfer (write) to SPI, and then read - I need to PULSE CS pin?

19:55 <Fleck> w/o pulse it seems like the chip stays at write mode and never responds...

19:56 <Fleck> MAX31865 in this case...

19:57 <Fleck> or maybe I am trying to read too fast, hmm...

19:58 <Fleck> *too soon

20:36 <Steffann> If its mandatory it would be in the datasheet;)

20:47 <Fleck> well, kinda, if you know it, then while reading datasheet, you may get a feeling thats the case :D did not find it clearly stated tho, thats why I asked, maybe it's by default so

21:00 <urja> how else would the chip know when the write ends...

21:03 <Fleck> yeah, that kinda makes sense urja! :)