Re: [gentoo-user] log4j
On Wed, Dec 15, 2021, 15:40 William Kenworthy wrote:
> I was reading up on log4j and its recent problems and discovered it can
> "hide" layers deep inside java jar files depending on how its used.
>
> I can see that dev-embedded/arduino includes log4j directly (and does it
> embed log4j in code produced for IoT?):
>
> rattus ~ # locate *.jar|grep 4j
> /usr/share/arduino/lib/log4j-api-2.12.0.jar
> /usr/share/arduino/lib/log4j-core-2.12.0.jar
> /usr/share/arduino/lib/slf4j-api-1.7.22.jar
> /usr/share/arduino/lib/slf4j-simple-1.7.22.jar
> rattus ~ #
>
> BUT there are a lot of other jar files on my systems which have log4j
> embedded in it.
>
These are likely coming in as transitive dependencies from other
dependencies that might be shaded. Any dependencies pulling log4j need to
updated. Easier said than done obviously.
> Sylf (not in portage that I can see) seems like it can build an SBOM for a
> target (Software Bill of Materials) that could identify deeply embedded
> log4j instances - has anyone used this on a gentoo system (it looks like it
> needs to specifically target a distro) or is there something
> easier/better? "strings|grep log4j" works on the arduino jar files but
> that wont work on propriety encrytpted jar files (such as propriety apps
> where it may likely be used). And is doing just jar files enough?
>
> BillK
>
> ** try something like 'find /opt /lib64 /usr/share -name *.jar -print
> -exec strings {} \; |grep log4j'
>
[gentoo-user] log4j
I was reading up on log4j and its recent problems and discovered
it can "hide" layers deep inside java jar files depending on how
its used.
I can see that dev-embedded/arduino includes log4j directly (and
does it embed log4j in code produced for IoT?):
rattus ~ # locate *.jar|grep 4j
/usr/share/arduino/lib/log4j-api-2.12.0.jar
/usr/share/arduino/lib/log4j-core-2.12.0.jar
/usr/share/arduino/lib/slf4j-api-1.7.22.jar
/usr/share/arduino/lib/slf4j-simple-1.7.22.jar
rattus ~ #
BUT there are a lot of other jar files on my systems which have
log4j embedded in it.
Sylf (not in portage that I can see) seems like it can build an
SBOM for a target (Software Bill of Materials) that could identify
deeply embedded log4j instances - has anyone used this on a gentoo
system (it looks like it needs to specifically target a distro) or
is there something easier/better? "strings|grep log4j" works on
the arduino jar files but that wont work on propriety encrytpted
jar files (such as propriety apps where it may likely be used).
And is doing just jar files enough?
BillK
** try something like 'find /opt /lib64 /usr/share -name *.jar
-print -exec strings {} \; |grep log4j'
Re: [gentoo-user] Correct procedure to install AMD64 multilib?
On Thu, Dec 16, 2021 at 10:26 AM Wol wrote: > And expect to get bit by the freetype/harfbuzz circular dependency. > There's plenty of stuff out there how to get round it, but it can be a > pain ... > Specifically you can look here if you have a problem with that. That's how I was able to sort that dependency out. https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Circular_dependencies#harfbuzz_and_freetype -- Sincerely, Jamie
Re: [gentoo-user] Correct procedure to install AMD64 multilib?
On 15/12/2021 09:53, Marco Rebhan wrote: Nope, but to actually get 32-bit libraries built in most cases you will need to set the USE_EXPAND ABI_X86=32 on the packages you need it for (don't set it globally, that's unnecessary). Probably automatically needed if you install the Android toolkit via portage. And expect to get bit by the freetype/harfbuzz circular dependency. There's plenty of stuff out there how to get round it, but it can be a pain ... Cheers, Wol
Re: [gentoo-user] Local mail delivery agent (MDA) wanted
On 12/15/21 1:21 PM, Laurence Perkins wrote:
So one thing that's annoyed me for a while is that there are several
things which will pull in nullmailer to accept local mails, but don't
pull in anything to do local delivery (And I'm not sure if nullmailer
can even pass things to local delivery) so your local delivery mails
by default just stack up in the nullmailer outbound queue unless you
configure it to pass them off to an external mail system.
Since the most commonly used of these programs are things like cron
where local delivery is probably the only thing most users would
care about it might be nice if the default configuration were one
that does that, and then those who want local mail relayed elsewhere
still don't have any significant extra setup work to do.
The idea of having a default mail configuration that would deliver
locally originated messages (e.g. from cron) to local user's mailboxes
(mbox) in /var(/spool)/mail makes sense to me.
I don't think I'd /personally/ us it b/c I run full MTAs on all my
systems. But that's /me/. I realize that I'm atypical.
But I would +1 a simple config that does local delivery from " |
mail ${USER}" to end up in "/var/spool/mail/${USER}".
--
Grant. . . .
unix || die
RE: [gentoo-user] Local mail delivery agent (MDA) wanted
> > >-Original Message- >From: Grant Taylor >Sent: Tuesday, December 14, 2021 3:34 PM >To: gentoo-user@lists.gentoo.org >Subject: Re: [gentoo-user] Local mail delivery agent (MDA) wanted > >On 12/13/21 3:12 PM, Frank Steinmetzger wrote: >>> Using strace, I found out that mail from mailx puts those mail into >>> /var/spool/clientmqueue/, one file per mail, but not in a maildir structure. > >Yes, the /var/spool/clientmqueue is the mail queue for outgoing messages from >clients. Hence the name "client m(ail) queue". > >> OK, I found out that this is the usual outgoing queue which needs to >> be processed by sendmail, probably through another cronjob or a >> process that itself checks that directory periodically. > >Sendmail is quintessentially a daemon that's running all the time. As such it >usually does it's own scheduling and does not depend on external scheduling. > >>> In many places I read that system mail—by default—goes into >>> /var/spool/mail/, but until now I’ve yet to observe this behavior. > >/var/spool/mail/ and /var/mail/ are the quintessential locations >for mbox based inbound email storage. > >Note: There are a number of other fancy client mail storage routines that >don't use files in this path. > >> It’s really not easy to find a description of the default setup of >> olden days (or I’m simply using the wrong search terms). Because when >> you search for something like unix local mail setup, most results are >> about setting up an SMTP server. In hindsight—perhaps that is simply >> the way to go. :-/ >You will quite likely need a Mail Transfer Agent to receive the email, either >via command (mail(x) / sendmail / etc) or read from a queue location like >/var/spool/clientmqueue and then deliver the messages to where they belong. > >There /may/ be an alternate "mail" command that does all of this in one >function. But I'd be surprised to learn about such. > >Most of the surprise is because it would be combining three distinct parts of >the email flow: the Mail User Agent (a.k.a. MUA) generating the original >outgoing message, the Message Transfer Agent (a.k.a. MTA) to receive the >original message and do something with it, and the Local Delivery Agent >(a.k.a. LDA) to put the message in the proper location. > >The originating MUA can frequently be substituted at will with "mail", >"mailx", and "nail" being three CLI based that come to mind immediately. > >The MTA can frequently be one of many with Sendmail, Postfix, Courier, Exim >coming to mind. > >The LDA can easily be one of the following; procmail, maildrop, Courier, > and something super simple I don't remember the name of because I've not > used it in so long. > > > >-- >Grant. . . . >unix || die > > So one thing that's annoyed me for a while is that there are several things which will pull in nullmailer to accept local mails, but don't pull in anything to do local delivery (And I'm not sure if nullmailer can even pass things to local delivery) so your local delivery mails by default just stack up in the nullmailer outbound queue unless you configure it to pass them off to an external mail system. Since the most commonly used of these programs are things like cron where local delivery is probably the only thing most users would care about it might be nice if the default configuration were one that does that, and then those who want local mail relayed elsewhere still don't have any significant extra setup work to do. LMP
