Re: RFE: use patchwork to submit a patch
On Mon, Oct 14, 2019 at 11:28:59AM -0300, Mauro Carvalho Chehab wrote:
Yeah, our current security model is based at the maintainer for
him to do his duties, properly reviewing the patch.
Yet, at the example that Daniel gave:
Instead of:
if ((permissions == allowed) && other_stuff) {
do_things();
}
do_more_stuff(permissions);
Patch was maliciously modified to:
if ((permission == allowed) && other_stuff) {
do_things();
}
do_more_stuff(permissions);
I suspect that a change like that might sleep though the maintainer's
review.
I submitted a proposal to the git list that would address this, but it
saw little uptake in the discussion:
https://public-inbox.org/git/20190910121324.GA6867@pure.paranoia.local/t/#u
To summarize it in brief, I suggested using minisign signatures and
git-tracked TOFU (trust on first use) databases. TOFU is not perfect,
but it's better than nothing at all, which is what we have right now.
-K
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Mon, 14 Oct 2019 10:38:51 +1100 Daniel Axtens wrote: > > It does bring up that any new workflow has to have security protocol > > and threat model as part of its design. > > This is actually something that worries me about the patchwork > workflow. Maintainers seem to trust the patchwork version of a patch > without much (or any) verification that it matches what was sent to the > list. I tend to download the patch from patchwork, and review that. When I find something to comment on, I go back to my INBOX and reply to the original patch where I want to comment on. Thus, what's in patchwork is what I have verified anyway. -- Steve ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Em Mon, 14 Oct 2019 08:26:37 -0400 "Theodore Y. Ts'o" escreveu: > On Mon, Oct 14, 2019 at 12:42:36PM +0200, Toke Høiland-Jørgensen wrote: > > It should be detectable, though, right? > > > > Say you have two independently administered patchwork instances (or even > > better, two different software packages entirely) that both subscribe to > > the mailing lists, and compare patch content with each other. They > > should at least be able to detect mismatches. Especially if you add a > > sanity check before discarding duplicate message-ids. > > They don't even need to compare against each other; patchwork is about > to add a feature where you can look up patches via message-id, right? > That means it's easy enough to write a program which fetches patches > from patchwork, and compares it to the patches found in > lore.kernel.org. If they don't match, then an alarm can be sounded. > > Individuals who are reviewing patches can also compare the copy in > their inbox with the copy from lore or some other public inbox. And > maintainers can compare copies from lore.kernel.org and patchwork > before they apply a patch. (99% of the time, I actually use the patch > from my inbox, anyway.) It can still have man-in-the-middle (MITM) attacks between the sender and vger.kernel.org. Please notice that using https and adding the patch via a web interface can also be subject to MITM, as companies and even some Countries with strong policy enforcement may have some gateway on their infra that will prevent end-to-end encryption[1], blocking direct client-server https tunnels. [1] They add an internal certificate to the browsers, so that the client will see the connection as trustful, but the infra will actually do two separate HTTPS encryption: client ---> Gateway Gateway ---> Server While unlikely, nothing prevents that the patch would be maliciously altered at the Gateway. From security PoV, the only way to ensure that the patch was not altered is to have it signed by the one who wrote it. > > > This way you'd need to compromise multiple machines to achieve the kind > > of compromise you're worried about. And you can add more independent > > machines until you're satisfied that the risk is low enough :) > > Yep, exactly. This is basically the theory behind Certificate > Transparency[1], applied to patches. For example, here's the > certificate transparency report for kernel.org: > > > https://transparencyreport.google.com/https/certificates?cert_search=domain:kernel.org > > - Ted > > [1] http://www.certificate-transparency.org/what-is-ct That won't prevent companies/governments to require the manual installation of the gateway's certificate on their browers, in order to be able to navigate using https. Thanks, Mauro ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Em Mon, 14 Oct 2019 09:53:58 -0400
"Theodore Y. Ts'o" escreveu:
> On Mon, Oct 14, 2019 at 10:41:32AM -0300, Mauro Carvalho Chehab wrote:
> > It can still have man-in-the-middle (MITM) attacks between the sender and
> > vger.kernel.org. Please notice that using https and adding the patch
> > via a web interface can also be subject to MITM, as companies and even some
> > Countries with strong policy enforcement may have some gateway on their
> > infra that will prevent end-to-end encryption[1], blocking direct
> > client-server https tunnels.
> >
> > [1] They add an internal certificate to the browsers, so that the client
> > will see the connection as trustful, but the infra will actually do two
> > separate HTTPS encryption:
> >
> > client ---> Gateway
> > Gateway ---> Server
> >
> > While unlikely, nothing prevents that the patch would be maliciously
> > altered at the Gateway.
> >
> > From security PoV, the only way to ensure that the patch was not
> > altered is to have it signed by the one who wrote it.
>
> Well, sure, but the maintainer should be reviewing the patch looking
> for problems anyway. There is the risk that people might slap a
> "Reviewed-by:" tag on a patch without sufficiently careful review if
> it's from a prominent kernel contributor, but we've always had that
> problem. And so nothing, not even a digitally signed patch from a
> reviewer should absolve the maintainer from doing their own review.
Yeah, our current security model is based at the maintainer for
him to do his duties, properly reviewing the patch.
Yet, at the example that Daniel gave:
Instead of:
if ((permissions == allowed) && other_stuff) {
do_things();
}
do_more_stuff(permissions);
Patch was maliciously modified to:
if ((permission == allowed) && other_stuff) {
do_things();
}
do_more_stuff(permissions);
I suspect that a change like that might sleep though the maintainer's
review.
>
> Now, one might argue that if there is a forged patch from "famous
> kernel developer A", followed up with a forged patch from "famous
> kernel developer B", that might cause a maintainer to happily take the
> patch without doing their own, independent review, for scaling
> reasons. But that's a "vulernability" we've lived with for a long
> time, since today neither patches or "Reviewed-by" messages are
> usually signed.
>
> And at least (as far as we know) no one has managed to sneak a
> malicious patch with a zero-day hidden with malice aforethought. And
> perhaps that shouldn't be surprising. We seem to be quite capable of
> introducing our own security vulererabilities without "help", so
> perhaps most malicious attackers wouldn't want to do something which
> could be so easily detected, when they can just pay money to a black
> hat hacker.
True, but, once we discover a patch introduced with a malicious code,
some action should be taken to eliminate the source of the bad code.
I mean, one thing is if "famous kernel developer A" maliciously
wrote a patch to violate security. The other thing is that the
infra used by "famous kernel developer A" is not safe, and has
some hidden back hat hacker in the middle of it.
The only way to identify that is by using signed patches/PRs.
Thanks,
Mauro
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Hi Eric,
On Mon, Oct 14, 2019 at 2:12 AM Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > On Fri, Oct 11, 2019 at 09:23:08PM +, Eric Wong wrote:
> > > > (This is the same reason I generally disagree with Eric Wong about
> > > > preserving SMTP as the primary transmission protocol -- I've heard lots
> > > > of
> > > > complaints both from kernel developers and especially from people
> > > > trying to
> > > > contribute to CAF about corporate policies actually making it
> > > > impossible to
> > > > submit patches -- and no, using a different mail server is not a
> > > > possibility
> > > > for them because it can be a firing offense under their IT AUP rules.)
> > >
> > > I'm not opposed to a webmail interface tailored to kernel hacking
> > > which does stuff like checkpatch.pl and get_maintainer.pl before
> > > sending (similar to your patchwork proposal and
> > > gitgadgetgadget). That would get around security appliances
> > > but SMTP would still be used in the background.
> > >
> > > Or offer full-blown HTTPS webmail + IMAP + SMTP access like any
> > > other webmail provider + checkpatch + get_maintainer helpers.
> >
> > Well, this is the bit where I say that it may not be allowed by corporate
> > rules. I see this all the time in CAF/Android world where companies
> > *require* that all email goes through their SMTP server so that it can be
> > properly logged (often for legal reasons). And it is often equally required
> > that any code submissions come from per...@corporate.com and not
> > per...@free-email-provider.com for License/CLA reasons, so setting up a
> > webmail server is not a solution either.
>
> Aren't they still allowed to submit stuff via forges the same way
> they'd use a potential hacker-oriented webmail/SMTP/IMAP solution?
>
> Sometimes I see @username_COMPANY-type names on forges, but
> AFAIK it's not very common.
>
> > This is basically why SMTP sucks in my view -- and it's worthless trying to
> > pick fights with IT departments, because they are told to do so by lawyers.
> > So, I want to take SMTP out of the equation:
>
> If the open source community can fight to get GPL accepted, I
> don't see why we can't fight or subvert dumb corporate policies.
>
> > 1. provide a way for someone to submit a patch using a web interface (but
> > still in a way that From: is their corporate ID)
> > 2. use individual git feeds as a way to send out patches instead of always
> > being secondary to SMTP
>
> username-comp...@users.kernel.org could probably work if they're
> required to use @username_COMPANY on forges.
username+foo is the standard way.
> We can also find creative ways to subvert corporate policies:
> For example; if their policy specifically prevents outgoing SMTP,
> "git imap-send" could be used.
IMAP may be blocked, too?
Bascially the only thing you can rely on is HTTP(S), through a proxy,
possibly with HTTPS inspection through a company-specific trusted
certificate that allows MITM.
> If their policy forbids using external "email" services, we'd
> name it "Kernel Hackers' Messaging System" or something of that
> sort and say we use an email bridge :>
Anything named "Hacker" may be blocked, too ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Sat, Oct 12, 2019 at 09:19:11AM +0200, Greg KH wrote: > On Fri, Oct 11, 2019 at 05:35:53PM -0400, Konstantin Ryabitsev wrote: > > 1. provide a way for someone to submit a patch using a web interface (but > > still in a way that From: is their corporate ID) > If you do this, what happens when a maintainer/reviewer responds to that > patch and says "looks good, but can you change X and resend it?" > How will they get that message if it didn't go through their email > system? How will they be able to respond to it? If they're using their work e-mail address like Konstantin says they'll get the reply there. Probably any response from them will be some top posted thing with HTML but this happens often enough currently - people often use git send-email or something to send but continue using a mail setup that's not really what's expected for kernel work. Usually it's not the end of the world even if people get a bit grumpy at them. signature.asc Description: PGP signature ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Geert Uytterhoeven wrote: > On Mon, Oct 14, 2019 at 2:12 AM Eric Wong wrote: > > We can also find creative ways to subvert corporate policies: > > For example; if their policy specifically prevents outgoing SMTP, > > "git imap-send" could be used. > > IMAP may be blocked, too? Yes, was just pointing to "git imap-send" which already exists; but anything can go over HTTPS POST + Transfer-Encoding:chunked. > Bascially the only thing you can rely on is HTTP(S), through a proxy, > possibly with HTTPS inspection through a company-specific trusted > certificate that allows MITM. Right, I was tunneling arbitrary data over HTTP/1.1 via Transfer-Encoding:chunked on both requests/responses over a decade ago. Probably won't work with nginx because of input buffering, but public-inbox-httpd can be made to support it w/o buffering, too (it already does HTTPS + chunk parsing). I got something working on the server-side for git:// using Ruby back in 2009: https://public-inbox.org/git/20090702085440.gc11...@dcvr.yhbt.net/ Client-side needed some work, though... > > If their policy forbids using external "email" services, we'd > > name it "Kernel Hackers' Messaging System" or something of that > > sort and say we use an email bridge :> > > Anything named "Hacker" may be blocked, too ;-) Unpxref, then :> ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Mon, Oct 14, 2019 at 10:41:32AM -0300, Mauro Carvalho Chehab wrote: > It can still have man-in-the-middle (MITM) attacks between the sender and > vger.kernel.org. Please notice that using https and adding the patch > via a web interface can also be subject to MITM, as companies and even some > Countries with strong policy enforcement may have some gateway on their > infra that will prevent end-to-end encryption[1], blocking direct > client-server https tunnels. > > [1] They add an internal certificate to the browsers, so that the client > will see the connection as trustful, but the infra will actually do two > separate HTTPS encryption: > > client ---> Gateway > Gateway ---> Server > > While unlikely, nothing prevents that the patch would be maliciously > altered at the Gateway. > > From security PoV, the only way to ensure that the patch was not > altered is to have it signed by the one who wrote it. Well, sure, but the maintainer should be reviewing the patch looking for problems anyway. There is the risk that people might slap a "Reviewed-by:" tag on a patch without sufficiently careful review if it's from a prominent kernel contributor, but we've always had that problem. And so nothing, not even a digitally signed patch from a reviewer should absolve the maintainer from doing their own review. Now, one might argue that if there is a forged patch from "famous kernel developer A", followed up with a forged patch from "famous kernel developer B", that might cause a maintainer to happily take the patch without doing their own, independent review, for scaling reasons. But that's a "vulernability" we've lived with for a long time, since today neither patches or "Reviewed-by" messages are usually signed. And at least (as far as we know) no one has managed to sneak a malicious patch with a zero-day hidden with malice aforethought. And perhaps that shouldn't be surprising. We seem to be quite capable of introducing our own security vulererabilities without "help", so perhaps most malicious attackers wouldn't want to do something which could be so easily detected, when they can just pay money to a black hat hacker. - Ted ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
"Theodore Y. Ts'o" writes: > On Mon, Oct 14, 2019 at 12:42:36PM +0200, Toke Høiland-Jørgensen wrote: >> It should be detectable, though, right? >> >> Say you have two independently administered patchwork instances (or even >> better, two different software packages entirely) that both subscribe to >> the mailing lists, and compare patch content with each other. They >> should at least be able to detect mismatches. Especially if you add a >> sanity check before discarding duplicate message-ids. > > They don't even need to compare against each other; patchwork is about > to add a feature where you can look up patches via message-id, right? > That means it's easy enough to write a program which fetches patches > from patchwork, and compares it to the patches found in > lore.kernel.org. If they don't match, then an alarm can be sounded. Yeah. I guess what is needed is to go from "can be" to "will be" (as Daniel pointed out in his simultaneous reply). >> This way you'd need to compromise multiple machines to achieve the kind >> of compromise you're worried about. And you can add more independent >> machines until you're satisfied that the risk is low enough :) > > Yep, exactly. This is basically the theory behind Certificate > Transparency[1], applied to patches. Indeed I'm familiar with certificate transparency, so this was certainly not an idea conceived in a vacuum ;) -Toke ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Mon, Oct 14, 2019 at 12:42:36PM +0200, Toke Høiland-Jørgensen wrote: > It should be detectable, though, right? > > Say you have two independently administered patchwork instances (or even > better, two different software packages entirely) that both subscribe to > the mailing lists, and compare patch content with each other. They > should at least be able to detect mismatches. Especially if you add a > sanity check before discarding duplicate message-ids. They don't even need to compare against each other; patchwork is about to add a feature where you can look up patches via message-id, right? That means it's easy enough to write a program which fetches patches from patchwork, and compares it to the patches found in lore.kernel.org. If they don't match, then an alarm can be sounded. Individuals who are reviewing patches can also compare the copy in their inbox with the copy from lore or some other public inbox. And maintainers can compare copies from lore.kernel.org and patchwork before they apply a patch. (99% of the time, I actually use the patch from my inbox, anyway.) > This way you'd need to compromise multiple machines to achieve the kind > of compromise you're worried about. And you can add more independent > machines until you're satisfied that the risk is low enough :) Yep, exactly. This is basically the theory behind Certificate Transparency[1], applied to patches. For example, here's the certificate transparency report for kernel.org: https://transparencyreport.google.com/https/certificates?cert_search=domain:kernel.org - Ted [1] http://www.certificate-transparency.org/what-is-ct ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Daniel Axtens writes:
>> It does bring up that any new workflow has to have security protocol
>> and threat model as part of its design.
>
> This is actually something that worries me about the patchwork
> workflow. Maintainers seem to trust the patchwork version of a patch
> without much (or any) verification that it matches what was sent to the
> list.
>
> Say Alice emails a patch that says something like:
>
> if ((permissions == allowed) && other_stuff) {
> do_things();
> }
> do_more_stuff(permissions);
>
> List members read that email, and many review it in the email client.
>
> However, say that the version in Patchwork actually reads like this:
>
> if ((permission = allowed) && other_stuff) {
> do_things();
> }
> do_more_stuff(permissions);
>
> (You could get this with a malicious/compromised patchwork admin, or a
> sufficiently advanced network adversary - patchwork takes the first mail
> for a given message-id + project and later ones are discarded, so
> there's a race you can win.)
>
> If the maintainer or someone else happens to apply the patch from
> patchwork and then review it, or if tests happen to catch the relevant
> case, we'll catch this. Otherwise...
>
> It's not the easiest or lowest risk way to get malicious code into the
> kernel, but nonetheless, I worry about it.
>
> I can't think of a sensible way to fix this, unless we want to move to a
> world where patch submissions are GPG signed, and teach patchwork to
> verify sigs.
It should be detectable, though, right?
Say you have two independently administered patchwork instances (or even
better, two different software packages entirely) that both subscribe to
the mailing lists, and compare patch content with each other. They
should at least be able to detect mismatches. Especially if you add a
sanity check before discarding duplicate message-ids.
This way you'd need to compromise multiple machines to achieve the kind
of compromise you're worried about. And you can add more independent
machines until you're satisfied that the risk is low enough :)
-Toke
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Konstantin Ryabitsev wrote: > On Fri, Oct 11, 2019 at 09:23:08PM +, Eric Wong wrote: > > > (This is the same reason I generally disagree with Eric Wong about > > > preserving SMTP as the primary transmission protocol -- I've heard lots of > > > complaints both from kernel developers and especially from people trying > > > to > > > contribute to CAF about corporate policies actually making it impossible > > > to > > > submit patches -- and no, using a different mail server is not a > > > possibility > > > for them because it can be a firing offense under their IT AUP rules.) > > > > I'm not opposed to a webmail interface tailored to kernel hacking > > which does stuff like checkpatch.pl and get_maintainer.pl before > > sending (similar to your patchwork proposal and > > gitgadgetgadget). That would get around security appliances > > but SMTP would still be used in the background. > > > > Or offer full-blown HTTPS webmail + IMAP + SMTP access like any > > other webmail provider + checkpatch + get_maintainer helpers. > > Well, this is the bit where I say that it may not be allowed by corporate > rules. I see this all the time in CAF/Android world where companies > *require* that all email goes through their SMTP server so that it can be > properly logged (often for legal reasons). And it is often equally required > that any code submissions come from per...@corporate.com and not > per...@free-email-provider.com for License/CLA reasons, so setting up a > webmail server is not a solution either. Aren't they still allowed to submit stuff via forges the same way they'd use a potential hacker-oriented webmail/SMTP/IMAP solution? Sometimes I see @username_COMPANY-type names on forges, but AFAIK it's not very common. > This is basically why SMTP sucks in my view -- and it's worthless trying to > pick fights with IT departments, because they are told to do so by lawyers. > So, I want to take SMTP out of the equation: If the open source community can fight to get GPL accepted, I don't see why we can't fight or subvert dumb corporate policies. > 1. provide a way for someone to submit a patch using a web interface (but > still in a way that From: is their corporate ID) > 2. use individual git feeds as a way to send out patches instead of always > being secondary to SMTP username-comp...@users.kernel.org could probably work if they're required to use @username_COMPANY on forges. We can also find creative ways to subvert corporate policies: For example; if their policy specifically prevents outgoing SMTP, "git imap-send" could be used. If their policy forbids using external "email" services, we'd name it "Kernel Hackers' Messaging System" or something of that sort and say we use an email bridge :> ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Mon, Oct 14, 2019 at 04:58:17PM +0200, Dmitry Vyukov wrote: > As one data point, I cannot send emails with git send-email anymore. > It used to work, then broke and I don't know how to fix it. Now it says: > > 5.7.8 Username and Password not accepted. Learn more at > 5.7.8 https://support.google.com/mail/?p=BadCredentials > s10sm8376885wrr.5 - gsmtp > > I suspect it has something to do with two factor auth. > So that's it: it cannot contribute to kernel right now. > I will not consider time spent fixing it as useful time investment. Note that this is a Googler-specific problem, as it's due to corp-security requirements that other GMail users and most GSuites customers won't have. (For example, you could use another SMTP server and bypass the corp. mail submission server, but for google.com e-mail addresses, the DMARC settings foreclose that particular workaround.) So it's an extreme case, and is an example of corp e-mail insanity. The good news is that for companies that are really serious about working with upstream, they will roll out solutions for their own customers. For example, with IBM, since Lotus notes was maximally unfriendly to OSS development practices, they created a separate mail system with l...@linux.ibm.com addresses be cause it was simply impossible to engage with upstream development using ibm.com addresses. So there are work arounds, and I encourage you to reach out to other Google kernel developers --- and if you are unhappy, please file internal bugs against the corp infrastructure. Personally, my solution to this problem is to use a non-google address (ty...@mit.edu) for upstream work, because life is too short to fight with GMail. (Although it is doable; as many people can attest.) > I would say that we need to aim at a process that does not require a > friendly experienced person to answer any of your questions in the > common case. Lots of people will simply not ask any questions. If you work inside a corporation with "unique" e-mail settings, you may need to ask a friendly experienced person inside your company, or look for the "new employee" (Noogler) web documentation for working with the kernel. - Ted ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Hi Konstantin, On Fri, Oct 11, 2019 at 05:35:53PM -0400, Konstantin Ryabitsev wrote: > On Fri, Oct 11, 2019 at 09:23:08PM +, Eric Wong wrote: > >> (This is the same reason I generally disagree with Eric Wong about > >> preserving SMTP as the primary transmission protocol -- I've heard lots of > >> complaints both from kernel developers and especially from people trying to > >> contribute to CAF about corporate policies actually making it impossible to > >> submit patches -- and no, using a different mail server is not a > >> possibility > >> for them because it can be a firing offense under their IT AUP rules.) > > > > I'm not opposed to a webmail interface tailored to kernel hacking > > which does stuff like checkpatch.pl and get_maintainer.pl before > > sending (similar to your patchwork proposal and > > gitgadgetgadget). That would get around security appliances > > but SMTP would still be used in the background. > > > > Or offer full-blown HTTPS webmail + IMAP + SMTP access like any > > other webmail provider + checkpatch + get_maintainer helpers. > > Well, this is the bit where I say that it may not be allowed by > corporate rules. I see this all the time in CAF/Android world where > companies *require* that all email goes through their SMTP server so > that it can be properly logged (often for legal reasons). And it is > often equally required that any code submissions come from > per...@corporate.com and not per...@free-email-provider.com for > License/CLA reasons, so setting up a webmail server is not a solution > either. > > This is basically why SMTP sucks in my view -- and it's worthless trying > to pick fights with IT departments, because they are told to do so by > lawyers. So, I want to take SMTP out of the equation: > > 1. provide a way for someone to submit a patch using a web interface >(but still in a way that From: is their corporate ID) > 2. use individual git feeds as a way to send out patches instead of >always being secondary to SMTP If the goal is to work around SMTP-related technical issues, is a web UI really the best way to go ? Wouldn't it be better to do the same through a git push ? We could setup a git server that requires authentication, and implement a push-to-email bridge. The information that would need to be entered in a web UI could be put in a tag message, and we could have a CLI to create the tag from a list of questions. -- Regards, Laurent Pinchart ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
Hi Greg, On Mon, Oct 14, 2019 at 05:17:11PM +0200, Greg KH wrote: > On Mon, Oct 14, 2019 at 04:58:17PM +0200, Dmitry Vyukov wrote: > > On Fri, Oct 11, 2019 at 7:20 PM Shuah Khan wrote: > > > On 10/11/19 2:57 AM, Greg KH wrote: > > > > On Thu, Oct 10, 2019 at 10:41:50AM -0400, Konstantin Ryabitsev wrote: > > > >> Hi, all: > > > >> > > > >> I would like to propose a new (large) feature to patchwork with the > > > >> goal to > > > >> make the process of submitting a patch easier for newbies and people > > > >> generally less familiar with patch-based development. This was > > > >> discussed > > > >> previously on the workflows list: > > > >> https://lore.kernel.org/workflows/20190930202451.GA14403@pure.paranoia.local/ > > > >> > > > >> How I envision this would work: > > > >> > > > >> - user creates an account (which requires a mail confirmation) >> - > > > >> they choose a "submit patch" option from the menu > > > >> - the patch submission screen has a succession of screens: > > > >> > > > >> 1. a screen with a single field allowing a user to paste a URL to > > > >> their > > > >> fork of the git repository. Once submitted, patchwork does a "git > > > >> ls-remote" to attempt to get a list of refs and to verify that > > > >> this is > > > >> indeed a valid git repository > > > > > > > > s/valid git repository/valid git repository based on the kernel git > > > > tree/ > > > > > > > > Otherwise you might be sending out lots of emails for other projects :) > > > > > > > >> > > > >> 2. next screen asks the user to select the ref to work from using the > > > >> list obtained from the remote. Once submitted, patchwork performs a > > > >> `git > > > >> clone --reference` to clone the repository locally using a local > > > >> fork of > > > >> the same repo to minimize object transfer. This part requires that: > > > >>a. patchwork project is configured with a path to a local fork, > > > >> if this feature is enabled for a project > > > >>b. that fork is kept current via some mechanism outside of > > > >> patchwork (e.g. with grokmirror) > > > >>c. there is some sanity-checking during the clone process to > > > >> avoid abuse (e.g. a sane timeout, a tmpdir with limited size, > > > >> etc > > > >> -- other suggestions welcome) > > > >> > > > >> 3. next screen asks the user to pick a starting commit from the log. > > > >> Once submitted, patchwork generates the patch from the commit > > > >> provided > > > >> to the tip of the branch selected by the user earlier, > > > >> using git format-patch. > > > >> > > > >> 4. next screen asks the user to review the patch to make sure this is > > > >> what they want to submit. Once confirmed, patchwork performs two > > > >> admin-defined optional hooks: > > > >> > > > >>a. a hook to generate a list of cc's (e.g. get_maintainer.pl) > > > >>b. a sanity check hook (e.g. checkpatch.pl) > > > > > > > > I will note that many "first patch" submissions are checkpatch.pl > > > > cleanups for staging. When doing that, I require that they do "one > > > > logical change per patch", which means that many of the individual > > > > patches themselves will not be checkpatch.pl clean, because many lines > > > > have multiple issues with them (tabs, spaces, format, length, etc.) > > > > > > > > So other than that minor thing, sounds interesting. It's hard to > > > > determine just how difficult the whole "set up git and send a patch out" > > > > process is for people these days given the _huge_ numbers of new > > > > contributions we keep getting, and the numerous good tutorials we have > > > > created that spell out exactly how to do this. > > > > > > > > So you might be "solving" a problem that we don't really have. It's > > > > hard to tell :( > > > > > > > > > > I agree with this. I don't think this a problem that is worth solving. > > > When a new developer wants to send a patch, they don't need to create > > > any accounts. They setup their email client and send patch. > > > > > > We have several resources that walk them through setting up email > > > clients and sending patches. checkpatch.pl can be automated with > > > git hooks. > > > > > > >> I know this is a pretty big RFE, and I would like to hear your thoughts > > > >> about this. If there is general agreement that this is doable/good > > > >> idea, I > > > >> may be able to come up with funding for this development as part of the > > > >> overall tooling improvement proposal. > > > > > > > > The workflow seems sane, and matches what most people do today, with the > > > > exception that it "solves" the git send-email issue, right? Is that our > > > > biggest barrier? > > > > > > > > I would recommend interviewing some of the recent kernel mentor project > > > > and outreachy applicants first, to try to determine exactly what their > > > > problems, if any, were with our development process. If they say that > > > > this type of
Re: RFE: use patchwork to submit a patch
Hi Dmitry, On Mon, Oct 14, 2019 at 04:58:17PM +0200, Dmitry Vyukov wrote: > On Fri, Oct 11, 2019 at 7:20 PM Shuah Khan wrote: > > On 10/11/19 2:57 AM, Greg KH wrote: > >> On Thu, Oct 10, 2019 at 10:41:50AM -0400, Konstantin Ryabitsev wrote: > >>> Hi, all: > >>> > >>> I would like to propose a new (large) feature to patchwork with the goal > >>> to > >>> make the process of submitting a patch easier for newbies and people > >>> generally less familiar with patch-based development. This was discussed > >>> previously on the workflows list: > >>> https://lore.kernel.org/workflows/20190930202451.GA14403@pure.paranoia.local/ > >>> > >>> How I envision this would work: > >>> > >>> - user creates an account (which requires a mail confirmation) >> - they > >>> choose a "submit patch" option from the menu > >>> - the patch submission screen has a succession of screens: > >>> > >>> 1. a screen with a single field allowing a user to paste a URL to > >>> their > >>> fork of the git repository. Once submitted, patchwork does a "git > >>> ls-remote" to attempt to get a list of refs and to verify that this is > >>> indeed a valid git repository > >> > >> s/valid git repository/valid git repository based on the kernel git tree/ > >> > >> Otherwise you might be sending out lots of emails for other projects :) > >> > >>> 2. next screen asks the user to select the ref to work from using the > >>> list obtained from the remote. Once submitted, patchwork performs a > >>> `git > >>> clone --reference` to clone the repository locally using a local fork > >>> of > >>> the same repo to minimize object transfer. This part requires that: > >>>a. patchwork project is configured with a path to a local fork, > >>> if this feature is enabled for a project > >>>b. that fork is kept current via some mechanism outside of > >>> patchwork (e.g. with grokmirror) > >>>c. there is some sanity-checking during the clone process to > >>> avoid abuse (e.g. a sane timeout, a tmpdir with limited size, etc > >>> -- other suggestions welcome) > >>> > >>> 3. next screen asks the user to pick a starting commit from the log. > >>> Once submitted, patchwork generates the patch from the commit provided > >>> to the tip of the branch selected by the user earlier, > >>> using git format-patch. > >>> > >>> 4. next screen asks the user to review the patch to make sure this is > >>> what they want to submit. Once confirmed, patchwork performs two > >>> admin-defined optional hooks: > >>> > >>>a. a hook to generate a list of cc's (e.g. get_maintainer.pl) > >>>b. a sanity check hook (e.g. checkpatch.pl) > >> > >> I will note that many "first patch" submissions are checkpatch.pl > >> cleanups for staging. When doing that, I require that they do "one > >> logical change per patch", which means that many of the individual > >> patches themselves will not be checkpatch.pl clean, because many lines > >> have multiple issues with them (tabs, spaces, format, length, etc.) > >> > >> So other than that minor thing, sounds interesting. It's hard to > >> determine just how difficult the whole "set up git and send a patch out" > >> process is for people these days given the _huge_ numbers of new > >> contributions we keep getting, and the numerous good tutorials we have > >> created that spell out exactly how to do this. > >> > >> So you might be "solving" a problem that we don't really have. It's > >> hard to tell :( > > > > I agree with this. I don't think this a problem that is worth solving. > > When a new developer wants to send a patch, they don't need to create > > any accounts. They setup their email client and send patch. > > > > We have several resources that walk them through setting up email > > clients and sending patches. checkpatch.pl can be automated with > > git hooks. > > > >>> I know this is a pretty big RFE, and I would like to hear your thoughts > >>> about this. If there is general agreement that this is doable/good idea, I > >>> may be able to come up with funding for this development as part of the > >>> overall tooling improvement proposal. > >> > >> The workflow seems sane, and matches what most people do today, with the > >> exception that it "solves" the git send-email issue, right? Is that our > >> biggest barrier? > >> > >> I would recommend interviewing some of the recent kernel mentor project > >> and outreachy applicants first, to try to determine exactly what their > >> problems, if any, were with our development process. If they say that > >> this type of tool/workflow would have saved them hours of time and > >> energy, then that's a great indication that we should try to do this. > > > > I would say considering the number of applicants to mentorship program > > and new developers it will be lot overhead to require them to create > > patchwork accounts, and it might even be hard overtime. A lot of them > > start out and drop out in the
Re: pwclient list issues
On Sat, Oct 12, 2019 at 8:22 AM Stephen Finucane wrote:
>
> On Thu, 2019-09-19 at 11:49 -0500, Bjorn Helgaas wrote:
> > No doubt this is user or installation error, but I haven't a clue. My
> > ~/.pwclientrc:
> >
> > [options]
> > default = linux-pci
> >
> > [linux-pci]
> > url = https://patchwork.ozlabs.org/xmlrpc/
> >
> > On pwclient HEAD (dc50416ff1b5 ("trivial: noqa duplicate import")),
> > some things work:
> >
> > $ ~/.local/bin/pwclient list -w Liebergeld -s New
> > Patches submitted by Steffen Liebergeld
> > :
> > ID StateName
> > -- -
> > 1163961 New [v2] PCI: quirks: Fix register location for UPDCR
> >
> > But others don't:
> >
> > $ ~/.local/bin/pwclient list -d lorpie01 -s New
> > Note: Nobody found matching *lorpie01*
> >
> > $ ~/.local/bin/pwclient list -d bhelgaas -s New
> > Patches delegated to Bjorn Helgaas :
> > Traceback (most recent call last):
> > File "/home/bhelgaas/.local/bin/pwclient", line 10, in
> > sys.exit(main())
> > File
> > "/home/bhelgaas/.local/lib/python2.7/site-packages/pwclient/shell.py", line
> > 129, in main
> > patches.action_list(rpc, filt, submitter_str, delegate_str,
> > format_str)
> > File
> > "/home/bhelgaas/.local/lib/python2.7/site-packages/pwclient/patches.py",
> > line 144, in action_list
> > patches = rpc.patch_list(f.d)
> > File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in __call__
> > return self.__send(self.__name, args)
> > File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request
> > verbose=self.__verbose
> > File "/usr/lib/python2.7/xmlrpclib.py", line 1283, in request
> > return self.single_request(host, handler, request_body, verbose)
> > File "/usr/lib/python2.7/xmlrpclib.py", line 1316, in single_request
> > return self.parse_response(response)
> > File "/usr/lib/python2.7/xmlrpclib.py", line 1493, in parse_response
> > return u.close()
> > File "/usr/lib/python2.7/xmlrpclib.py", line 800, in close
> > raise Fault(**self._stack[0])
> > xmlrpclib.Fault: :Cannot
> > query "Bjorn Helgaas ": Must be "User" instance.'>
>
> I somehow managed to miss this email, but I assume you managed to work
> around this with git-pw? This sounds like a bug with the XML-RPC API
> and we're probably not going to bother fixing it at this point. The
> REST API provides all the same functionality (and more!) and we'll be
> dropping the XML-RPC API in 3.0 (the next version once 2.2 is out the
> door) so it's not worth the effort. I hope to port pwclient to the REST
> API shortly but until then, just use git-pw :)
I did eventually git this to work with git-pw (after kernel.org
updated patchwork).
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
