Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 719212 - sys-auth/pambase calls cpp directly
Summary: sys-auth/pambase calls cpp directly
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mikle Kolyada
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks: tc-directly
  Show dependency tree
 
Reported: 2020-04-24 11:09 UTC by Agostino Sarubbo
Modified: 2020-07-03 16:36 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,11.14 KB, text/plain)
2020-04-24 11:09 UTC, Agostino Sarubbo
Details
#gentoo-qa.irclog (qa.irclog,7.86 KB, text/plain)
2020-06-14 08:13 UTC, Kent Fredric (IRC: kent\n)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2020-04-24 11:09:38 UTC
This is an auto-filled bug because sys-auth/pambase calls cpp directly.
The issue was originally discovered on amd64, but it may be reproducible on other arches as well.
Attached build log and emerge --info.

NOTE:
This issue has been reproduced by setting the CPP variable and by removing the /usr/bin/cpp binary.
Comment 1 Agostino Sarubbo gentoo-dev 2020-04-24 11:09:44 UTC
Created attachment 634362 [details]
build.log

build log and emerge --info
Comment 2 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-04-24 11:11:21 UTC
well, no point to make it not directly.
Comment 3 Alessandro Barbieri 2020-04-24 16:00:48 UTC
Please reopen the bug
This isn't the right mentality for a developer of a source based distro
The point is to build every package with the compiler the user want (example: clang)
Also a member of the QA team wontfixing QA issues launches bad signs about the status of the whole distro
Comment 4 Sergei Trofimovich gentoo-dev 2020-05-25 10:37:05 UTC
For those who follow along the correct fix is to always try toolchain-prefixed tool first:

$ diff -U3 pambase-20200304.ebuild pambase-20200304-r1.ebuild | cat
--- pambase-20200304.ebuild	2020-03-26 18:01:10.000000000 +0000
+++ pambase-20200304-r1.ebuild	2020-05-25 11:31:22.000000000 +0100
@@ -3,6 +3,8 @@

 EAPI=7

+inherit toolchain-funcs
+
 DESCRIPTION="PAM base configuration files"
 HOMEPAGE="https://github.com/gentoo/pambase"
 SRC_URI="https://github.com/gentoo/pambase/archive/${P}.tar.gz"
@@ -58,6 +60,7 @@

 	emake \
 		GIT=true \
+		CPP="$(tc-getPROG CPP cpp)" \
 		$(use_var debug) \
 		$(use_var LIBCAP caps) \
 		$(use_var cracklib) \
@@ -79,5 +82,5 @@
 src_test() { :; }

 src_install() {
-	emake GIT=true DESTDIR="${ED}" install
+	emake GIT=true CPP="$(tc-getPROG CPP cpp)" DESTDIR="${ED}" install
 }
Comment 5 Kent Fredric (IRC: kent\n) gentoo-dev 2020-06-12 10:47:52 UTC
Reopening until either a hard verdict by QA stating:
- This doesn't matter
- This should be fixed

Or the bug itself (which seems to have a trivial solution) is fixed.
Comment 6 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-06-12 11:57:16 UTC
As long as there is no the outcome I prefer the status quo. Please do not reopen the bugs you are not responsible for. Think you.
Comment 7 Kent Fredric (IRC: kent\n) gentoo-dev 2020-06-12 12:39:42 UTC
After discussion with QA team lead, this bug should stay open.
Comment 8 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-06-12 12:56:28 UTC
(In reply to Kent Fredric (IRC: kent\n) from comment #7)
> After discussion with QA team lead, this bug should stay open.

I have different information at hand.
Comment 9 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-06-12 13:44:20 UTC
(In reply to Kent Fredric (IRC: kent\n) from comment #7)
> After discussion with QA team lead, this bug should stay open.

figured, although pambase is under slow restoration (really slow). This bug is not a priority.
Comment 10 Sergei Trofimovich gentoo-dev 2020-06-12 17:11:12 UTC
Anything wrong with patch from #comment4?
Comment 11 David Seifert gentoo-dev 2020-06-12 18:01:49 UTC
(In reply to Sergei Trofimovich from comment #10)
> Anything wrong with patch from #comment4?

Looks fine, even though we really need to fix pambase properly
Comment 12 Sergei Trofimovich gentoo-dev 2020-06-12 18:10:18 UTC
(In reply to David Seifert from comment #11)
> (In reply to Sergei Trofimovich from comment #10)
> > Anything wrong with patch from #comment4?
> 
> Looks fine, even though we really need to fix pambase properly

Can you elaborate? Is it about restructuring something upstream? What specifically? Or in ebuilds?

Looking at required behaviour from 'cpp' it looks like pambase needs an 'unifdef'.
Comment 13 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-06-12 19:27:12 UTC
(In reply to Sergei Trofimovich from comment #12)
> (In reply to David Seifert from comment #11)
> > (In reply to Sergei Trofimovich from comment #10)
> > > Anything wrong with patch from #comment4?
> > 
> > Looks fine, even though we really need to fix pambase properly
> 
> Can you elaborate? Is it about restructuring something upstream? What
> specifically? Or in ebuilds?
> 
> Looking at required behaviour from 'cpp' it looks like pambase needs an
> 'unifdef'.

Meant to be "in source" fix as I am the upstream of the pambase for now, naturally.
Comment 14 Sergei Trofimovich gentoo-dev 2020-06-12 21:01:11 UTC
(In reply to Mikle Kolyada from comment #13)
> (In reply to Sergei Trofimovich from comment #12)
> > (In reply to David Seifert from comment #11)
> > > (In reply to Sergei Trofimovich from comment #10)
> > > > Anything wrong with patch from #comment4?
> > > 
> > > Looks fine, even though we really need to fix pambase properly
> > 
> > Can you elaborate? Is it about restructuring something upstream? What
> > specifically? Or in ebuilds?
> > 
> > Looking at required behaviour from 'cpp' it looks like pambase needs an
> > 'unifdef'.
> 
> Meant to be "in source" fix as I am the upstream of the pambase for now,
> naturally.

What specifically should be changed upstream?
Comment 15 Kent Fredric (IRC: kent\n) gentoo-dev 2020-06-13 04:52:59 UTC
(In reply to Sergei Trofimovich from comment #14)

> What specifically should be changed upstream?

I believe the objective is to simply not abuse CPP as a general macro language. ( The rest of the code isn't C-like at all )

If you have a look at what pambase installs....

/etc/pam.d/su
/etc/pam.d/system-remote-login
/etc/pam.d/other
/etc/pam.d/system-login
/etc/pam.d/system-services
/etc/pam.d/system-local-login
/etc/pam.d/passwd
/etc/pam.d/system-auth
/etc/pam.d/login

These are all just text-files compiled by CPP-macros.
Comment 16 Sergei Trofimovich gentoo-dev 2020-06-13 07:16:40 UTC
(In reply to Kent Fredric (IRC: kent\n) from comment #15)
> (In reply to Sergei Trofimovich from comment #14)
> 
> > What specifically should be changed upstream?
> 
> I believe the objective is to simply not abuse CPP as a general macro
> language.

Would be nice it it was stated here by the maintainer to corroborate. Along with more detailed plan what should be done so someone could implement it and why workaround from #comment4 can't be applied meanwhile.

Also let's add +qa@ explicitly to officially answer #comment5 to have a path forward in this bug.
Comment 17 Kent Fredric (IRC: kent\n) gentoo-dev 2020-06-13 08:38:43 UTC
> Would be nice it it was stated here by the maintainer to corroborate. Along
> with more detailed plan what should be done so someone could implement it
> and why workaround from #comment4 can't be applied meanwhile.
> 
> Also let's add +qa@ explicitly to officially answer #comment5 to have a path
> forward in this bug.

Already had a conversation about this bug in #gentoo-qa , so I don't think they need further contribution.

As long as this is fixed some way eventually ( as in, the proposed mechanism to remove the need to use CPP for macro handling in upstream code, would also solve this bug by way to removing CPP usage entirely ), having this bug open till it goes away is the least I can ask for.

Though I do suspect the patching is completely appropriate, the understood "risk" is that by using user-overrideable CPP, they could somehow override CPP in such a way that it installs broken pam-base files, which would possibly break authentication entirely, and that's something that should be avoided.
Comment 18 Sergei Trofimovich gentoo-dev 2020-06-13 19:56:55 UTC
(In reply to Kent Fredric (IRC: kent\n) from comment #17)
> > Would be nice it it was stated here by the maintainer to corroborate. Along
> > with more detailed plan what should be done so someone could implement it
> > and why workaround from #comment4 can't be applied meanwhile.
> > 
> > Also let's add +qa@ explicitly to officially answer #comment5 to have a path
> > forward in this bug.
> 
> Already had a conversation about this bug in #gentoo-qa , so I don't think
> they need further contribution.

Post the log with the decision here please.
Comment 19 Kent Fredric (IRC: kent\n) gentoo-dev 2020-06-14 08:13:27 UTC
Created attachment 644618 [details]
#gentoo-qa.irclog

As requested. Not much interesting to see.
Comment 20 Thomas Deutschmann gentoo-dev Security 2020-07-02 19:18:39 UTC
Any reason why we can't merge the proposed ebuild change? Looks straight forward.
Sure, if maintainer wants to fix pambase itself bug could stay open but why block other Gentoo devs who want to fix their package to work with USE=-native-symlinks and depend on pambase in the meanwhile?
Comment 21 Larry the Git Cow gentoo-dev 2020-07-03 09:55:41 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b6864f38b6121ce01254e367dbd44cd3e9838a2

commit 3b6864f38b6121ce01254e367dbd44cd3e9838a2
Author:     David Seifert <soap@gentoo.org>
AuthorDate: 2020-07-03 09:55:26 +0000
Commit:     David Seifert <soap@gentoo.org>
CommitDate: 2020-07-03 09:55:26 +0000

    sys-auth/pambase: Fix USE="native-symlinks"
    
    Closes: https://bugs.gentoo.org/719212
    Package-Manager: Portage-2.3.103, Repoman-2.3.23
    Suggested-by: Sergei Trofimovich <slyfox@gentoo.org>
    Signed-off-by: David Seifert <soap@gentoo.org>

 sys-auth/pambase/pambase-20190402.ebuild | 5 ++++-
 sys-auth/pambase/pambase-20191128.ebuild | 5 ++++-
 sys-auth/pambase/pambase-20200304.ebuild | 5 ++++-
 sys-auth/pambase/pambase-20200618.ebuild | 5 ++++-
 4 files changed, 16 insertions(+), 4 deletions(-)
Comment 22 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-07-03 10:13:42 UTC
(In reply to Thomas Deutschmann from comment #20)
> Any reason why we can't merge the proposed ebuild change? Looks straight
> forward.
> Sure, if maintainer wants to fix pambase itself bug could stay open but why
> block other Gentoo devs who want to fix their package to work with
> USE=-native-symlinks and depend on pambase in the meanwhile?

Actually because I am not fond of unprofessional ugly fixes (yes, sounds strong, but it is), but if soap takes responsibility for that, I am also ok.
Comment 23 Sergei Trofimovich gentoo-dev 2020-07-03 16:28:52 UTC
(In reply to Mikle Kolyada from comment #22)
> (In reply to Thomas Deutschmann from comment #20)
> > Any reason why we can't merge the proposed ebuild change? Looks straight
> > forward.
> > Sure, if maintainer wants to fix pambase itself bug could stay open but why
> > block other Gentoo devs who want to fix their package to work with
> > USE=-native-symlinks and depend on pambase in the meanwhile?
> 
> Actually because I am not fond of unprofessional ugly fixes (yes, sounds
> strong, but it is)

This statement provides zero information on the nature of the problem you have with the "ugly fix". The question was asked at least 3 time how do you want fix to look like (this is the fourth one). I saw no answer.
Comment 24 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-07-03 16:30:48 UTC
(In reply to Sergei Trofimovich from comment #23)
> (In reply to Mikle Kolyada from comment #22)
> > (In reply to Thomas Deutschmann from comment #20)
> > > Any reason why we can't merge the proposed ebuild change? Looks straight
> > > forward.
> > > Sure, if maintainer wants to fix pambase itself bug could stay open but why
> > > block other Gentoo devs who want to fix their package to work with
> > > USE=-native-symlinks and depend on pambase in the meanwhile?
> > 
> > Actually because I am not fond of unprofessional ugly fixes (yes, sounds
> > strong, but it is)
> 
> This statement provides zero information on the nature of the problem you
> have with the "ugly fix". The question was asked at least 3 time how do you
> want fix to look like (this is the fourth one). I saw no answer.

And you have been told at least twice by soap and me.
Comment 25 Sergei Trofimovich gentoo-dev 2020-07-03 16:36:28 UTC
(In reply to Mikle Kolyada from comment #24)
> (In reply to Sergei Trofimovich from comment #23)
> > (In reply to Mikle Kolyada from comment #22)
> > > (In reply to Thomas Deutschmann from comment #20)
> > > > Any reason why we can't merge the proposed ebuild change? Looks straight
> > > > forward.
> > > > Sure, if maintainer wants to fix pambase itself bug could stay open but why
> > > > block other Gentoo devs who want to fix their package to work with
> > > > USE=-native-symlinks and depend on pambase in the meanwhile?
> > > 
> > > Actually because I am not fond of unprofessional ugly fixes (yes, sounds
> > > strong, but it is)
> > 
> > This statement provides zero information on the nature of the problem you
> > have with the "ugly fix". The question was asked at least 3 time how do you
> > want fix to look like (this is the fourth one). I saw no answer.
> 
> And you have been told at least twice by soap and me.

Then I missed it. Can you post a link?