[bitbake-devel] [PATCH 0/1] bitbake: fetch2/git: fix initial http authed clone

[Middelschulte, Leif]

Hello Olof,

thank you for your reply.
I appologize for the late reply, I was out of office.

Am Dienstag, den 04.06.2019, 19:38 +0200 schrieb Olof Johansson:
> On 19-06-04 18:01 +0200, Leif Middelschulte wrote:
> > This patch fixes initial clones of git repositories authenticated
> > via basic http authentication. This became apparent when code was
> > reused to clone submodules too.
> > 
> > The method is the recommended way of cloning source code by CI
> > runners. This patch fixes the currently broken behvior.
> 
> Hi,
> 
> Recommended by whom specifically?
By "recommended", I was referring to cloning source code via HTTPs
within CIs, by using dynamically created/valid tokens:
https://docs.gitlab.com/ee/ci/triggers/README.html#ci-job-token

I was not referring to the URI scheme specifically.

> Encoding passwords in URIs was
> deprecated RFC 3986 for security reasons. Some tools may not be
> aware of security sensitive information contained in URIs.
> 
> RFC 3986:
> > Applications should not render as clear text any data after the
> > first colon (":") character found within a userinfo
> > subcomponent ...
> 
> Having passwords and security sensitive info in the bitbake
> metadata also seems a bit weird to me, but bb.fetch2.decodeurl()
> does support extracting it. 
I'm whitelisting an environment variable (CI_JOB_TOKEN) before I
source a bitbake environment. So the credentials are not hard-coded,
but use the following format within SRC_URIs:
user=gitlab-ci-runner:${CI_JOB_TOKEN};protocol=https
It used to be supported (rocko). Apparently unintended. It was just this
behavioral break (in warrior) that lead me creating this patch.

> I thought the git fetcher didn't
> support auth details (other than user) via the URI by design, but
> this is just my assumption.
AFAICS git indeed supports specifying complete credentials as via
the URI.
> 
> The gitcredentials manpage recommends using the global
> configuration with [credential.<uri-pattern>] blocks to specify
> this instead.
> 
> https://git-scm.com/docs/gitcredentials
> 

Thank you for the hint. I'll use git's native integration then[0].

For the record:
git config --global credential.https://gitlab.example.com.username gitlab-ci-token
git config --global credential.https://gitlab.example.com.helper '!f() { echo "password=`echo $CI_JOB_TOKEN`"; }; f'

[0] https://git-scm.com/docs/api-credentials#_credential_helpers

So feel free to just drop this patch.

Again thanks for the feedback.

-- 
Best Regards,

KLS Martin GmbH + Co. KG,
A KLS Martin Group company
 
Leif Middelschulte
Software Development Engineer

KLS Martin GmbH + Co. KG 
Am Flughafen 18  79108 Freiburg im Breisgau / Germany
Telefon +49 (761) 557 997-543   Fax +49 (761) 557 997-520 
leif.middelschulte at klsmartin.com; www.klsmartin.com

Registergericht: Freiburg im Breisgau; Handelsregister: HRA 4044 
Geschäftsführer: Michael Martin, Karl Leibinger, Christian Leibinger 
Persönlich haftende Gesellschafterin: KLS Martin Verwaltungsgesellschaft mbH 
Registergericht: Stuttgart; Handelsregister: HRB 451316 
USt.-Id-Nr. DE 237467280 

Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. 

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this
e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.