Mailing List Archive

Ebuild: How to deal with external repositories properly (best practise)?
Hello list,

I have set up my first ebuild repository[1] with one package
"x11-misc/drm_master_util" to run "X" without root privileges. I am
still making it to work[2]. The ebuild file accesses an external git
repository[3].

The thing I am concerned about, is, that I am pulling something from an
external source, which I am installing on my system and giving it root
privileges[4].

The only best practise I can think of, is, to fork the external
repository, linking the ebuild to my fork and updating it on demand, so
I have full control over it.

Would this be the way to do it?

[1] https://codeberg.org/keks24/gentoo-overlay
[2] https://wiki.gentoo.org/wiki/User:Keks24/drafts/Non_root_Xorg
[3] https://github.com/gch1p/drm_master_util.git
[4] https://wiki.gentoo.org/wiki/Non_root_Xorg#Handling_of_DRM_ioctls
Re: Ebuild: How to deal with external repositories properly (best practise)? [ In reply to ]
On 2020-07-28 06:47+0200 Ramon Fischer <Ramon_Fischer@hotmail.de> wrote:

> […]
> The thing I am concerned about, is, that I am pulling something from
> an external source, which I am installing on my system and giving it
> root privileges[4].
>
> The only best practise I can think of, is, to fork the external
> repository, linking the ebuild to my fork and updating it on demand,
> so I have full control over it.
>
> Would this be the way to do it?

You can mask all packages from a repository in
/etc/portage/package.mask/ with
*/*::repo-name
and unmask the packages you want in /etc/portage/package.unmask/ with
x11-misc/drm_master_util::repo-name
or just the version you want with
=x11-misc/drm_master_util-9999::repo-name
.

The maintainer of the repo could still replace the ebuild with a
malware installer.
Re: Ebuild: How to deal with external repositories properly (best practise)? [ In reply to ]
On Tue, 28 Jul 2020 06:47:50 +0200, Ramon Fischer wrote:

> I have set up my first ebuild repository[1] with one package
> "x11-misc/drm_master_util" to run "X" without root privileges. I am
> still making it to work[2]. The ebuild file accesses an external git
> repository[3].
>
> The thing I am concerned about, is, that I am pulling something from an
> external source, which I am installing on my system and giving it root
> privileges[4].

Isn't that the case with any software you install? If your concern is
that you are pulling from a git repository, so the code could change at
any minute, you can use the git eclass to pull a specified branch or
commit, so you know what you are getting.


--
Neil Bothwick

Anything is possible if you don't know what
you are talking about.
Re: Ebuild: How to deal with external repositories properly (best practise)? [ In reply to ]
Hello tastytea,

I am aware of this "workaround", thank you. :)

I guess, I was not precise enough:

The ebuild "drm_master_util-9999"[1] is hosted on my repository, but the
ebuild file itself pulls in an external repository[2].

My question is: Is it a best practise to fork the external
repository[2], to link my fork with "drm_master_util-9999"[1], so I have
full control about updating the fork. Just to check, that the external
source is not doing shenanigans?

-Ramon

[1]
https://codeberg.org/keks24/gentoo-overlay/src/branch/master/x11-misc/drm_master_util/drm_master_util-9999.ebuild#L27
[2] https://github.com/gch1p/drm_master_util.git

On 28/07/2020 10:53, tastytea wrote:
> On 2020-07-28 06:47+0200 Ramon Fischer <Ramon_Fischer@hotmail.de> wrote:
>
>> […]
>> The thing I am concerned about, is, that I am pulling something from
>> an external source, which I am installing on my system and giving it
>> root privileges[4].
>>
>> The only best practise I can think of, is, to fork the external
>> repository, linking the ebuild to my fork and updating it on demand,
>> so I have full control over it.
>>
>> Would this be the way to do it?
> You can mask all packages from a repository in
> /etc/portage/package.mask/ with
> */*::repo-name
> and unmask the packages you want in /etc/portage/package.unmask/ with
> x11-misc/drm_master_util::repo-name
> or just the version you want with
> =x11-misc/drm_master_util-9999::repo-name
> .
>
> The maintainer of the repo could still replace the ebuild with a
> malware installer.
>
Re: Ebuild: How to deal with external repositories properly (best practise)? [ In reply to ]
On 2020-07-28 12:02+0200 Ramon Fischer <Ramon_Fischer@hotmail.de> wrote:

> Hello tastytea,
>
> I am aware of this "workaround", thank you. :)
>
> I guess, I was not precise enough:
>
> The ebuild "drm_master_util-9999"[1] is hosted on my repository, but
> the ebuild file itself pulls in an external repository[2].

Sorry, I misread your first email.

> My question is: Is it a best practise to fork the external
> repository[2], to link my fork with "drm_master_util-9999"[1], so I
> have full control about updating the fork. Just to check, that the
> external source is not doing shenanigans?

I would use either EGIT_COMMIT from git-r3.eclass¹ or download a
snapshot via SRC_URI².

¹ <https://devmanual.gentoo.org/eclass-reference/git-r3.eclass/index.html#lbAF>
² <https://github.com/gch1p/drm_master_util/archive/<COMMIT-HASH>.tar.gz>
Re: Ebuild: How to deal with external repositories properly (best practise)? [ In reply to ]
Oh yeah, as Neil was pointing that out.

I will give it a try and report soon.

-Ramon

On 28/07/2020 14:52, tastytea wrote:
> On 2020-07-28 12:02+0200 Ramon Fischer <Ramon_Fischer@hotmail.de> wrote:
>
>> Hello tastytea,
>>
>> I am aware of this "workaround", thank you. :)
>>
>> I guess, I was not precise enough:
>>
>> The ebuild "drm_master_util-9999"[1] is hosted on my repository, but
>> the ebuild file itself pulls in an external repository[2].
> Sorry, I misread your first email.
>
>> My question is: Is it a best practise to fork the external
>> repository[2], to link my fork with "drm_master_util-9999"[1], so I
>> have full control about updating the fork. Just to check, that the
>> external source is not doing shenanigans?
> I would use either EGIT_COMMIT from git-r3.eclass¹ or download a
> snapshot via SRC_URI².
>
> ¹ <https://devmanual.gentoo.org/eclass-reference/git-r3.eclass/index.html#lbAF>
> ² <https://github.com/gch1p/drm_master_util/archive/<COMMIT-HASH>.tar.gz>
>