Re: [arch-general] pambase update now requires explicit service files in /etc/pam.d/ - dovecot affected
On Tue, Feb 12, 2019 at 09:15:39AM -0500, Jens John wrote: > On Tue, 12 Feb 2019, at 12:02, Leonid Isaev via arch-general wrote: > > I am sorry to ask this so late in the discussion, but why Arch default of > > the > > "other" module was insecure (and hence why the change)? Is there something > > wrong with pam_unix? > > Not inherently. They implemented a suggestion from the upstream product > manual and decided that it was OK to break random [authentication related] > packages instead of fixing the reverse deps from official repos first and > then changing pambase. > > Either package maintenance responsibilities are really as fragmented as not > to care at all or they just ignored it. Given that falconindy is the > maintainer of pambase, I'll go with the latter interpretation (no judgement > implied). There is no problem with using upstream defaults (so I personally support the change to the pambase package), and I think that ppl should just fix their stuff to properly work with PAM. But I still don't understand why using pam_unix.so was called permissive policy... Thanks, -- Leonid Isaev
Re: [arch-general] pambase update now requires explicit service files in /etc/pam.d/ - dovecot affected
On Mon, Feb 11, 2019 at 11:54:22PM -0600, Doug Newgard via arch-general wrote: > On Mon, 11 Feb 2019 18:42:01 -0800 > frede...@ofb.net wrote: > > > I don't understand the need for that reaction... > > He posted that he's glad he broke the rules, implying that he'd gladly do it > again in the future. A strong reaction is not only warranted, but necessary. > I am sorry to ask this so late in the discussion, but why Arch default of the "other" module was insecure (and hence why the change)? Is there something wrong with pam_unix? Thanks, -- Leonid Isaev
Re: [arch-general] Missing auth.log
On Fri, Nov 16, 2018 at 01:43:17AM +0100, Maxe wrote: > Hi, > > One of our systems, running ARCH Linux, was compromised (a non-privileged > account, fortunately). But, we could not find /var/log/auth.log or similar > for investigation. Does the journal keep track of login attempts? It seems > that ARCH does not run [r]syslogd. If you want authpriv messages, then run "journalctl SYSLOG_FACILITY=10". See https://en.wikipedia.org/wiki/Syslog#Facility for mapping between numerical and mnemonic facility IDs. Oh, and do install syslog-ng :) Cheers, -- Leonid Isaev
Re: [arch-general] Firefox crashes randomly
On Thu, Sep 20, 2018 at 09:36:43PM +0200, Hubert Hauser via arch-general wrote: > Hello! > > How is your recommended space for shared memory (/dev/shm)? Will be > these instructions okay > (https://bbs.archlinux.org/viewtopic.php?id=68434)? How many memory is > allocated for /dev/shm by default? Half of the RAM size by default, as for any tmpfs... Cheers, -- Leonid Isaev
Re: [arch-general] AppArmor support
On Sun, Sep 09, 2018 at 06:13:24PM -0400, Eli Schwartz via arch-general wrote: > On 9/9/18 4:00 PM, Leonid Isaev via arch-general wrote: > > FWIW, I actually agree with #59733: CONFIG_AUDIT=n was blocking AppArmor > > adoption... Perhaps relevant: > > https://lists.debian.org/debian-devel/2017/08/msg00090.html . > > > > But I have a question: why was AUDIT enabled in the first place? I thought > > it > > was cosidered useless? > > It is definitely not useless! It's historically been disabled because it > did not have any good way to enable support, but keep it turned off by > default. And having it turned on by default came with mandatory > slowdowns for *all* users. > > Ironically, Spectre has proven to be our friend here -- due to all the > mitigations, there is now no fast path for these system calls, so your > kernel is just as slow whether AUDIT is enabled or not. Therefore, we > ended up simply enabling it. > Good to know. I remember arguments like "audit is primarily necessary for selinux that we don't have... Otherwise it just spams logs". In any case, audit=0 is the way to go for me. Cheers, L. -- Leonid Isaev
Re: [arch-general] AppArmor support
On Sun, Sep 09, 2018 at 10:19:37PM +0200, David Runge wrote: > FYI, > I'm currently working on bringing the user space tools to [community], but > the rule sets will require testing and possibly we'll even have to have our > own set shipped with the package. > > I'll let you know asap. Thanks and pls take your time. I have a VM that runs linux-hardened and is used to study malicious pdf files. I can test rulesets there... Cheers, L. -- Leonid Isaev
Re: [arch-general] AppArmor support
On Sun, Sep 09, 2018 at 02:53:04PM -0400, Eli Schwartz via arch-general wrote: > Heftig retracted his initial willingness to enable apparmor because he > did not think it useful enough without the userland tools. It wasn't > rejected because we hate the idea or consider it not Arch-like... it was > rejected because on its own, it could be considered not-important-enough > to warrant enabling. FWIW, I actually agree with #59733: CONFIG_AUDIT=n was blocking AppArmor adoption... Perhaps relevant: https://lists.debian.org/debian-devel/2017/08/msg00090.html . But I have a question: why was AUDIT enabled in the first place? I thought it was cosidered useless? Cheers, L. -- Leonid Isaev
Re: [arch-general] Services with DefaultDependencies=no
On Mon, Aug 27, 2018 at 12:51:13PM -0400, Eli Schwartz via arch-general wrote: > On 8/27/18 8:45 AM, Leonid Isaev via arch-general wrote: > > Hi, > > > > While going over .service files on my system, I noticed that quite a > > few of them, not belonging to systemd package, contain > > DefaultDependencies=no > > (DD=no). This is understandable (perhaps) for programs like > > systemd-journald, > > but what about normal daemons, like rpcbind, haveged and rpc-nfsd? I thought > > that setting DD=no is kind of a hack needed only for special services (e.g. > > called from fstab via x-systemd.requires=). Or am I missing something? > > DefaultDependencies=false means it won't get "ensure that the service is > started only after basic system initialization is completed and is > properly terminated on system shutdown." (from the systemd.unit(5) man > page). Yeah, systemd.service manpage is more relevant here. Because it says that daemons with DD=no are also not subject to the normal shutdown logic... > Seems like a reasonable thing to want to avoid for programs that are > meant to be started as part of initializing the system. Initialization or early boot? > e.g. you might want RPC daemons running as soon as possible. You most > likely do want haveged running as soon as possible. Actually, digging into nfs-utils I understand why devs did it (for NFS-mounted /var). But they also were careful to specify dependencies on services that are pulled as a part of basic and sysinit targets. I disagree with that decision because I might want to bring firewall (iptables.service obeys the normal DD logic) before NFS/rpcbind is started (I do it for port-forwarding RPCbind and ypserv calls into a container). But I'm really not sure why you'd need haveged in early boot (as opposed to inird), nor that it doesn't require any of the early-boot services... But thx anyway, -- Leonid Isaev
Re: [arch-general] update today causes avantfax_hourly cron: Exec format error?
On Mon, Aug 27, 2018 at 04:04:14PM +0200, Ralf Mardorf wrote: > On Mon, 27 Aug 2018 07:38:12 -0600, Leonid Isaev via arch-general wrote: > >On Mon, Aug 27, 2018 at 03:02:38PM +0200, Ralf Mardorf wrote: > >> Eli, wouldn't it be easier for you to ignore people who are not as > >> wise and psychologically balanced as you are? I doubt that anybody > >> of us is able to learn from your wise comments, more likely we laugh > >> at you, because we are psychically disturbed and dumb, so we don't > >> know better. > > > >Well, speak for yourself. And grow up and learn to avoid being > >disturbed by (deserved) critisism. > > Take a look at the Archive. Yeah, and the first post in this thread was about a script that broke because of a linux-firmware update. I stopped reading after that because it was clear that the person who wrote that didn't think at all... At least Eli took time to explain what actually went wrong. If Eli is mistaken, he is unable to admit > Consider to reread Eli's brilliant achievement of wisdom and online > psychotherapy: > >> I have run Arch on it since 2009 -- I'm familiar with what it > >> does. > > > >Just using a thing often used by intelligent, computer-savvy people, > >does not *automatically* qualify you as one of them. Just using a thing > >for a long time does not *automatically* qualify you as familiar with > >that thing. > > > >And in this case, your aggressively prioritized attitude of learned > >helplessness makes me wonder whether using Arch is the best thing for > >you. > > > >For reasons I don't quite understand, you seem to despise the idea of > >becoming more knowledgeable about how things work. I don't see how this > >can work out... Which I totally agree with and support: if you don't want to research problems, don't run Arch. There are plenty of good distros out there for you. Cheers, -- Leonid Isaev
Re: [arch-general] update today causes avantfax_hourly cron: Exec format error?
On Mon, Aug 27, 2018 at 03:02:38PM +0200, Ralf Mardorf wrote: > Eli, wouldn't it be easier for you to ignore people who are not as wise > and psychologically balanced as you are? I doubt that anybody of us is > able to learn from your wise comments, more likely we laugh at you, > because we are psychically disturbed and dumb, so we don't know better. Well, speak for yourself. And grow up and learn to avoid being disturbed by (deserved) critisism. Besides, for anyone knowledgeable it would always be easier to ignore other less knowledgeable people... But you see where this would end up. Cheers, -- Leonid Isaev
[arch-general] Services with DefaultDependencies=no
Hi, While going over .service files on my system, I noticed that quite a few of them, not belonging to systemd package, contain DefaultDependencies=no (DD=no). This is understandable (perhaps) for programs like systemd-journald, but what about normal daemons, like rpcbind, haveged and rpc-nfsd? I thought that setting DD=no is kind of a hack needed only for special services (e.g. called from fstab via x-systemd.requires=). Or am I missing something? Thanks, L. -- Leonid Isaev
Re: [arch-general] ClamAV Flagging systemd package
On Sat, Jul 14, 2018 at 05:19:29PM +0200, LoneVVolf wrote: > On 14-07-18 16:52, David Murray via arch-general wrote: > > Greetings, > > > > My nightly full-system ClamAV scan kicked out this last night: > > > > /var/cache/pacman/pkg/systemd-238.133-4-x86_64.pkg.tar.xz: > > Unix.Trojan.Vali-6606621-0 FOUND > > > > Is this something I should be concerned about? > > > > TIA, > > Dave > > > https://www.virustotal.com/#/file/1aef694958c06497a8c5e98b0e6914b2a9af48faff736fcb42e3855377ee8e19/detection > > That shows 2 engines that detect something, Baidu and ClamAV . > > https://pcfixguides.com/how-to-effectively-remove-unix-trojan-vali-6606621-0-from-your-computer/ > > It appears to be able to infect windows and Mac systems, and > does look threatening. > > Not sure who should look into this, but Arch Security Team > seems most applicable. > https://wiki.archlinux.org/index.php/Arch_Security_Team > > LW Nobody. What's the point of running a scan of a host from that host itself? And on top of that, the suspected malware has already been executed because you mention a pkg in the cache... Anyway, a brief google search reveals that this particular trojan turned up in many distros, so it is most likely a false positive. Cheers, -- Leonid Isaev
Re: [arch-general] [arch-dev-public] [core] / [extra] cleanup
On Sat, Jun 02, 2018 at 05:06:11PM +0200, Jelle van der Waa wrote: > *Move to [extra]* > > - ifenslave - Don't see why it is required in core, also orphan > - libgssglue/librpcsecgss - move to extra, nothing in [core] deps on it. > (archboot and nfs-utils used to dep on it) > - b43-fwcutter - Is this still required for more recent broadcom cards? What about logrotate? AFAIU, there are no loggers in [core]... Thanks, -- Leonid Isaev
Re: [arch-general] sshd - limiting sequential no. or files opened via sftp in kate?
[long email, so top-posting] MaxSessions and MaxStartups in /etc/ssh/sshd_config? Cheers, L. On Thu, Jun 07, 2018 at 01:44:37AM -0500, David C. Rankin wrote: > All, > > Not sure where to look for this. I have always kept kate projects different > things like, different application development, different web-site editing, > etc... Many of the projects I keep on my Arch server and have kate open the > files via the sftp kioslave (or whatever it is called now) > > For some reason, now when I open remote projects on the server, the first 15 > or so files open without issue. Anything over that fails with a connection > error and the files are opened as "Untitled" and are empty (simply pressing > "Reload" completes the opening without issue), but that has to occur after > kate is open, and not when the project is attempting to load the files > sequentially all at once. > > The journal shows no error, just the normal sshd key authorization, etc. as > session through (c17) are opened, e.g. > > Jun 07 01:29:04 valkyrie sshd[9269]: Accepted publickey for david from > 192.168.6.104 port 56170 ssh2: ECDSA > SHA256:97TPKWvaGks+sjneobeoY9RpK1Hznnh8xJCjbcAWrkQ > Jun 07 01:29:04 valkyrie sshd[9268]: Accepted publickey for david from > 192.168.6.104 port 56168 ssh2: ECDSA > SHA256:97TPKWvaGks+sjneobeoY9RpK1Hznnh8xJCjbcAWrkQ > Jun 07 01:29:04 valkyrie sshd[9269]: pam_unix(sshd:session): session opened > for user david by (uid=0) > Jun 07 01:29:04 valkyrie sshd[9268]: pam_unix(sshd:session): session opened > for user david by (uid=0) > Jun 07 01:29:04 valkyrie systemd-logind[539]: New session c5 of user david. > Jun 07 01:29:04 valkyrie systemd[1]: Started Session c5 of user david. > Jun 07 01:29:04 valkyrie systemd-logind[539]: New session c6 of user david. > Jun 07 01:29:04 valkyrie systemd[1]: Started Session c6 of user david. > Jun 07 01:29:05 valkyrie sshd[9274]: userauth_pubkey: key type ssh-dss not in > PubkeyAcceptedKeyTypes [preauth] > Jun 07 01:29:05 valkyrie sshd[9275]: userauth_pubkey: key type ssh-dss not in > PubkeyAcceptedKeyTypes [preauth] > Jun 07 01:29:05 valkyrie sshd[9272]: userauth_pubkey: key type ssh-dss not in > PubkeyAcceptedKeyTypes [preauth] > Jun 07 01:29:05 valkyrie sshd[9274]: Accepted publickey for david from > 192.168.6.104 port 56174 ssh2: ECDSA > SHA256:97TPKWvaGks+sjneobeoY9RpK1Hznnh8xJCjbcAWrkQ > Jun 07 01:29:05 valkyrie sshd[9274]: pam_unix(sshd:session): session opened > for user david by (uid=0) > Jun 07 01:29:05 valkyrie systemd-logind[539]: New session c7 of user david. > Jun 07 01:29:05 valkyrie systemd[1]: Started Session c7 of user david. > ... > > I don't see any failures at all in the logs, which I would expect given the > connection failure. Any ideas on what could be causing this? > > I don't any longer, but there were times in the past I would have 120 files > in a project and had no problems at all opening the project either across the > LAN or remotes via the internet on my office server. So this seems like it is > some protection designed to prevent hackers from hammering your server with > ssh requests -- but it seems like it is having the side effect of preventing > me from loading projects with more than say 20 files via sftp. > > -- > David C. Rankin, J.D.,P.E. -- Leonid Isaev
Re: [arch-general] Set ip lan address /etc/environment
On Fri, Jun 01, 2018 at 08:48:03AM +0200, Maykel Franco via arch-general wrote: > 2018-05-31 12:01 GMT+02:00 Leonid Isaev via arch-general > : > > On Thu, May 31, 2018 at 10:44:25AM +0100, Ralph Corderoy wrote: > >> Hi Maykel, > >> > >> > I need define variable called ip with current ip address machine... > >> > And when reboot machine, the variable ip always has ip address. > >> > >> Yes, I think we all figured that bit out. :-) > >> But why; what's going to be using that IP-address environment variable, > >> and when? > > > > Indeed. Is it for consumption of users whose shell you don't know? Is it for > > scripts, like cron jobs? > > > > In the former case, see what is in /etc/shells, and drop a script to > > /etc/profile.d, one for each shell. But that will be for login shells. In > > the > > latter case, I am afraid you need to define it each time... > > > > Finally, a bit of a puzzle, what are you going to do when the network goes > > down, i.e. should the variable be unset or updated? In other words, how > > certain > > are you that the IP address remains unchanged throughout the machine uptime? > > > > -- > > Leonid Isaev > > I need this for docker. I have docker services in which I use > variables and I want to pass the always updated ip variable. If the > network goes, it is not a problem, it will always have the same fixed > static ip. But this way I leave docker generalized for any pc. I don't understand: "the always updated ip variable" implies that it can change, no? In that case, storing it in a variable, won't track the changes. If the IP is really static, it must exist in some file, like netctl profile... Anyways, I think a better way is to write a shell function, like my_ip() that simply prints the IP address to stdout... Cheers, -- Leonid Isaev
Re: [arch-general] Set ip lan address /etc/environment
On Thu, May 31, 2018 at 10:44:25AM +0100, Ralph Corderoy wrote: > Hi Maykel, > > > I need define variable called ip with current ip address machine... > > And when reboot machine, the variable ip always has ip address. > > Yes, I think we all figured that bit out. :-) > But why; what's going to be using that IP-address environment variable, > and when? Indeed. Is it for consumption of users whose shell you don't know? Is it for scripts, like cron jobs? In the former case, see what is in /etc/shells, and drop a script to /etc/profile.d, one for each shell. But that will be for login shells. In the latter case, I am afraid you need to define it each time... Finally, a bit of a puzzle, what are you going to do when the network goes down, i.e. should the variable be unset or updated? In other words, how certain are you that the IP address remains unchanged throughout the machine uptime? -- Leonid Isaev
Re: [arch-general] Set ip lan address /etc/environment
On Wed, May 30, 2018 at 01:07:59PM +0200, Maykel Franco via arch-general wrote: > Hi, I put this text in /etc/environment: > > $ source /etc/environment > > ip="$(ifconfig | grep -A 1 'eth0' | tail -1 | cut -d ':' -f 2 | cut -d > ' ' -f 1)" > > $ echo $ip > > 192.168.0.33 > > Works fine, but when I reboot my archlinux: > > $ echo $ip > > $(ifconfig | grep -A 1 'eth0' | tail -1 | cut -d ':' -f 2 | cut -d ' ' -f 1) > > > What's happened?? Is necessary exec source /etc/environment after every > reboot? > > Thanks in advanced. /etc/environment is for PAM not shell, so it only allows ip=xxx.yyy.zzz.aaa . Also, /etc/profile is for LOGIN shells, meaning that from scripts or when doing scp(1) it won't be read. What exactly are you trying to achieve? Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Mon, May 14, 2018 at 11:01:57AM -0400, Eli Schwartz via arch-general wrote: > We're currently in feature freeze for pacman 5.1 > > Anyone who hopes to have b2sum support in *future* versions of pacman, > would be well advised to come across as a person seeking to extend > support for the current crop of common hashing algorithms, not someone > pushing b2sum because "secure all PKGBUILDs". > > For this reason, it would probably be useful to see coreutils support > more than one cherry-picked modern hashing algorithm. I'm not really > caring which ones those are, but then I'm also perfectly happy with > sha256/sha512 (which are both of them great algorithms which work > perfectly fine). > > So I'm uninterested in the bikeshed on general principle, and only > vaguely interested inasmuch as having more tools and more diversity in > the future would probably be interesting and/or useful. But I can find > lots of arguments for and against all the SHA3 candidates, some of them > rather bitter, so I see no reason to take sides. I agree... But I think that trying to identify the best algorithm is a waste of time because the only important feature is whether a given hash algorithm has been broken (in the sense of generating collisions). Everything else (performance, hash size, etc) is completely irrelevant for makepkg use... It would make sense to include B2B/SHA3 support in makepkg when we start seeing updtreams provide these hashes. Currently, AFAIK the only "upstream" doing that is Gentoo in their Manifests. Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Mon, May 14, 2018 at 11:23:39AM +0100, Ralph Corderoy wrote: > Hi Eli, > > > Maybe you could ask the coreutils developers whatever happened to > > implementing Keccak checksumming tools. > > SHA-3? Have you see > https://www.imperialviolet.org/2017/05/31/skipsha3.html > I've also seen suggestions that the Keccak team push Kangaroo Twelve > these days over SHA-3 due to SHA-3's comparative slowness. Of course, none of this is relevant for the present thread... Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Sun, May 13, 2018 at 08:19:19PM +0200, Neven Sajko via arch-general wrote: > On 13 May 2018 at 20:11, Neven Sajko wrote: > > I do agree that using md5 is absurd, ... > > To clarify, md5 *is* unsecure and is even slower or not significantly > faster than hashes from the Keccak and BLAKE2 families; using > signatures would be a plus but signatures are not an argument for md5. It is trivial to enable blake2 support in makepkg using b2sum(1) from the coreutils package. Currently, I only saw gentoo using it but I didn't do proper research on this... Yes, md5 is almost as good these days as crc32... It is ok if the sources are gpg-signed, but not on its own. Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Thu, May 10, 2018 at 10:06:08AM +0200, NicoHood wrote: > I really like you effort on stronger hashes. I totally aggree with you > that we need those, if we can't have GPG signatures by the maintainers. > Hashes just help in less usecases than GPG signatures, of course, but > they do. Currently, about 55% of [core] and 31% of [extra] packages make use of validpgpkeys. In [community] it should be even less. So, it is still a long way to go while all PKGBUILDs use GPG-verified sources... I agree with others that using a single sha256sum instead of md5sum offers questionable security benefit, but at least it protects against future tampering with the src by an attacker who knows about MD5 collisions. > Unfortunately I made the experience, that this discussion is useless > here and you rather start helping with GPG signatures for every package. > If you want to put effort into this topic, which I really appreciate, > please directly go for GPG signatures, otherway it will be just a > frustrating discussion for you, sadly. There are only about 13% of packages in both [core] and [extra] that use MD5 -- a relatively small percentage. Yes, replacing those with a stronger hash is a stop-gap measure, but it involves no maintainance overhead. When you brought up this point last December, I didn't know that it is possible to have concurrent CRC and MD5 collisions (ar at least they are difficult to find). But since then, I did some homework and it indeed seems quite easy these days. Therefore, using MD5 is no better than having SKIP. In this regard, I don't understand why we need checksums at all? If upstream: (1) signes source with GPG, it will take care of both integrity and authenticity, so no need for hashes; (2) doesn't provide signatures, rely on gzip/bzip2/xz CRC. It is not cryptographically secure, but we don't need that anyway. Hence, we can substantially simplify makepkg code... > What I can recommend to you for this is to write to upstream projects > who don't use GPG signatures yet. Explain them why its important and > help them to improve their software release security. I made the > experience that quite a lot of projects did not know about the > importance of GPG or just never looked into it. Just a few refuse to use > GPG, leave that for now. What about upstreams, like PAM, who stopped signing their releases? From a developer point of view, it makes sense to not have a GPG key because it implies an additional responsibility of keeping it safe. Therefore, I understand people who don't signed their src archives. > As additional support you can use the GPGit guides as well as the > automated (same named) GPGit tool: https://github.com/NicoHood/gpgit > It will help new users to understand GPG and provide them an easy to use > tool to get started with GPG within a few minutes. Feedback for this is > appreaciated. I don't think it's needed. GPG is not complicated at all. The difficulty that prevents its widespread use lies with maintaining the key, and with that no guide can help... > I wish you all good luck, dont hesitate to contact me further if you > have any great ideas regarding GPG etc. Thanks, L. -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote: > I would just like to note that SHA-2 hashes are inferior to Keccak and > to BLAKE2. So better not to spend effort migrating to SHA-2. Strength of various SHA hashes is a different topic. My only point was that relying on md5 these days is like having no hashes at all or using the source filename as a hash... And there should be no migration -- when a new version of a package is released or a rebuild happens, just update the *sums array. Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Wed, May 09, 2018 at 12:31:39AM -0400, Eli Schwartz via arch-general wrote: > PGP keys are also far more likely to appear in multiple independently > verifiable locations, you can embed them in your DNS records, post them > on your blog, github profile, keybase.io proofs utilizing DNS as well as > social media linkages, email footer (and signed email history) to > establish a difficult-to-falsify history, or simply follow the PGP web > of trust. It is all true. But... if I care to only do "makepkg -g >> PKGBUILD", then I'm unlikely to follow web of trust, and if I'm going to scout mailing lists for email footers, I will also scout debian, gentoo, alpine and fedora repos for different hashes. That was my only point, but we are mixing policy and technical issues. If hashes are supposed to mean that I'm building the same source as the maintainer, then using only md5sums negate this because the source can be silently swapped using existing libraries, and attackers don't even need to know mathematics behind md5 collisions... I agree that using strong hashes alone does not address security of source distribution, but neither does HTTPS for instance. At least, with sha-2 hashes, point #3 of your previous email makes sense. Thanks, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Tue, May 08, 2018 at 11:38:01PM -0400, Eli Schwartz via arch-general wrote: > When you say "still", that implies that there was any sort of effort to > change that in the first place... Fair enough :) I thought it's a slow natural process... > - not any sort of security check at all, they're there for CRC purposes, > and using strong CRC is security theater because the maintainer > probably just blindly ran updpkgsums without checking anything at all > so they generated very strong fake hashes -- come back when you have > PGP[1] which is actually security In this case, even using gpg keys won't guarantee security because verifying a key via a side channel is not much easier than the hash. > - actively dangerous as people think strong checksums equals security, > which makes them trust the sources even when they shouldn't; like > security theater except used as a justification for the other extreme Yes, but see [1] and [2]. At least with SHA hashes we are not so vulnerable. [1] http://cryptography.hyperlink.cz/2004/otherformats.html [2] https://www.mathstat.dal.ca/~selinger/md5collision > - better than nothing, and therefore very useful since it ensures that > you at least rebuilt the same thing the maintainer did No really, see just above. That is an old link, probably now forging .tar.gz files got much easier. > - very much security, because obviously the maintainer verifies sources > out of band, and checksums are their way of telling us what the > canonical sources are If (s)he does, then there will be multiple hashes, from different sources, no? > As extensively discussed in several mailing list and forum threads, the > best way to get security which everyone agrees on is to encourage > upstream developers to PGP-sign their sources. I've done quite a bit of > work on the existing TODO[1] which we have for implementing better PGP > checks (and HTTPS for both privacy and TLS endpoint verification), in > addition to providing the patchset[2] for makepkg (available in git > master and awaiting the 5.1 release) which allows verifying git(1) > signed commits/tags. Thanks for your work! I didn't know about those links, will check them out. But ok, I see your point... Thanks, L. -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Tue, May 08, 2018 at 08:08:31PM -0600, Leonid Isaev wrote: > [extra] > ... This list should also include "python-retrying". I should have grepped more carefully, sigh... -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Tue, May 08, 2018 at 08:08:31PM -0600, Leonid Isaev wrote: > [0] https://lists.archlinux.org/pipermail/arch-general/2016-December/042 Oops, this link should have been https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
Hi, I'm intentionally using the title from Nov/Dec 2016 [0] to ease googling. I decided to check the status of this, and there is still 325 packages with only md5sums in [core] and [extra] (I didn't check [community]). Below results are generated by the attached script... Is there anything I can do (like sending reports to the Flyspray) to help convert those PKGBUILD's to SHA hashes? Thanks, L. - Stats - Total: 325 [core]: 28 [extra]: 283 removed: 14 -- Repo breakdown -- [core] b43-fwcutter cracklib dmraid fakeroot filesystem flex hdparm ipw2100-fw ipw2200-fw libaio libgssglue libnsl librpcsecgss libsasl libusb licenses linux-atm nfsidmap nilfs-utils pam pcmciautils pptpclient reiserfsprogs sysfsutils usbutils which xinetd zd1211-firmware [extra] a52dec accounts-qml-module aiksaurus alsa-firmware alsa-lib antlr2 apricots archlinux-menus archlinux-themes-slim arptables aspell-de aspell-es aspell-fr aspell-nl assimp attica-qt4 autoconf2.13 automoc4 bigloo bird bluez-firmware bogofilter bootchart capi4hylafax celt celt0.5.1 chemtool chmlib claws-mail-themes compface convertlit convmv cpio cscope ctags cups-pdf cvsps cyrus-sasl dbus-sharp dbus-sharp-glib ddrescue dmapi docbook-mathml docbook-xml dotconf ebtables enscript exiv2 facile fakechroot festival ffcall freealut frozen-bubble fsarchiver gamin gconf-sharp gd gdome2 giblib giflib gnome-mime-data gnu-efi-libs gnu-netcat gob2 gtkglext gtkmathview guile1.8 gwaterfall habak hunspell-it hunspell-ro hwdetect hylafax hyphen-de hyphen-it hyphen-nl hyphen-ro icon-naming-utils ifplugd ijs ilmbase imap iniparser ipset jack java-commons-net1 java-gnumail java-inetlib java-jdepend java-jline java-resolver lablgtk2 ladspa lame libaccounts-glib libatasmart libcaca libcdaudio libdbusmenu-qt libdiscid libdmtx libfbclient libgadu libglade libglademm libid3tag libiec61883 libieee1284 libifp libirman liblangtag liblqr libmcrypt libmp3splt libmp4v2 libmpeg2 libmusicbrainz5 libnet libnss_nis libomxil-bellagio libshout libsignon-glib libstdc++5 libtommath libusb-compat libutempter libxkbui libxmi libyaml licq lockdown-ms lua51 lua52 luajson lzop metalog mjpegtools mkisolinux mkpxelinux mksyslinux mod_dnssd mozilla-common mp3splt mp3wrap mtdev munin musepack mysql-python mythes-de mythes-en mythes-fr mythes-it mythes-ro nawk ncftp npapi-sdk nss_ldap nss-mdns nuget openbabel openconnect openexr oxygen-gtk2 pam_ldap perl-appconfig perl-bit-vector perl-business-isbn-data perl-carp-clan perl-common-sense perl-config-simple perl-convert-binhex perl-crypt-openssl-rsa perl-crypt-passwdmd5 perl-crypt-ssleay perl-date-calc perl-digest-hmac perl-digest-nilsimsa perl-digest-sha1 perl-email-date-format perl-ev perl-event-execflow perl-extutils-depends perl-extutils-pkgconfig perl-fcgi perl-file-sharedir perl-file-which perl-gtk2-ex-formfactory perl-guard perl-html-parser perl-html-tagset perl-image-exiftool perl-ipc-system-simple perl-locale-gettext perl-log-log4perl perl-mail-spf perl-math-round perl-mime-lite perl-netaddr-ip perl-net-cidr-lite perl-net-ip perl-sdl perl-string-shellquote perl-sys-hostname-long perl-template-toolkit perl-term-readkey perl-text-iconv perl-tie-simple perl-timedate perl-xml-namespacesupport perl-xml-sax-base php-apcu php-apcu-bc pkgstats progsreiserfs protobuf psiconv psutils pulseaudio-alsa pyopengl pyqt4 pyrex pysmbc python2-configparser python-appdirs python-defusedxml python-fpconst python-geoip python-mccabe python-mpd python-nose python-notify python-soappy qrencode qt-assistant-compat raptor rasqal razor refind-efi rpcsvc-proto rpmextract sane sane-frontends sbc schroedinger scons sg3_utils signon-plugin-oauth2 signon-ui slim-themes snappy snarf sni-qt sonata sound-theme-freedesktop source-highlight spandsp speedtouch spice-protocol taglib telepathy-idle telepathy-salut testdisk tevent tftp-hpa thinkfinger tidy tree ttf-bitstream-vera unixodbc wicd xalan-java xerces2-java xerces-c xorg-fonts-100dpi xorg-fonts-75dpi xorg-fonts-alias xorg-fonts-cyrillic xorg-fonts-type1 xsane yajl zita-als
Re: [arch-general] procps-ng 3.3.13 and its new topdefaultrc
On Wed, Apr 11, 2018 at 03:20:10PM -0500, David C. Rankin wrote: > On 04/11/2018 12:08 PM, Eli Schwartz via arch-general wrote: > > It's ironic, I guess, that the procps-ng developers did this in order to > > provoke people into learning how to configure top, but now we have > > people preferring the old look, who complain when the default changes, > > and then when we revert to the old look we have people complaining about > > the old look, but no one seems interested in, well, configuring it as > > upstream intended... > > > > (Kudos to Jonathon for being principled enough in both desiring > > distro-customized defaults for Manjaro users and implementing them the > > right way. I wonder if anyone will actually learn how to use top though...) > > Did I miss something obvious? Are you suggesting there is a simply toprc flag > that allows choosing between old and new top interfaces? It should also be mentioned that ~/.toprc is the most hideous config file on my system :) And FWIW, I don't think that upstream wanted to provoke any learning -- they just made a change for the sake of it (probably following GNOME 3.x :). Cheers, -- Leonid Isaev
Re: [arch-general] Curious about arch repository policy
On Tue, Mar 27, 2018 at 08:39:30PM +0100, morganamilo via arch-general wrote: > > > On 27/03/18 20:34, Leonid Isaev via arch-general wrote: > > On Tue, Mar 27, 2018 at 08:27:16PM +0530, Sudarshan Kakoty via arch-general > > wrote: > > > Hello... > > > > > > I was reading "Arch Wiki" and felt curious about that difference > > > between extra and community repo. > > > > > > Some packages, such as "meson" is in the "extra" repo, whereas "ninja" > > > is in "community" repo. The interesting fact is that - is an implicit > > > dependency to "meson". So why that is (ninja) in the community repo? > > A more important question is why meson and ninja are not in [core] and base > > group given that they are build-dependencies of systemd? > > > > Cheers, > > L. > Probably because they're only make depends like you said. So in a user's > system make depends are not needed to install packages nor do they provide > any use. But I thought [core] was supposed to be self-contained, or it only used to be? Cheers, -- Leonid Isaev
Re: [arch-general] Curious about arch repository policy
On Tue, Mar 27, 2018 at 08:27:16PM +0530, Sudarshan Kakoty via arch-general wrote: > Hello... > > I was reading "Arch Wiki" and felt curious about that difference > between extra and community repo. > > Some packages, such as "meson" is in the "extra" repo, whereas "ninja" > is in "community" repo. The interesting fact is that - is an implicit > dependency to "meson". So why that is (ninja) in the community repo? A more important question is why meson and ninja are not in [core] and base group given that they are build-dependencies of systemd? Cheers, L. -- Leonid Isaev
Re: [arch-general] mandb - numerous parse failures on run (parallel, fribidi, numactl, pcre2, netpbm, etc..)
On Wed, Mar 14, 2018 at 07:37:30PM -0500, David C. Rankin wrote: > On 03/14/2018 06:55 PM, David C. Rankin wrote: > > Is this just something that is expected over time? > > I think the short answer is that the man-db service is not enabled by default. > Sorry for the noise here. man-db.service is triggered by man-db.timer which should be enabled on your system by default... Cheers, -- Leonid Isaev
Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting
On Tue, Mar 13, 2018 at 09:41:46AM -0400, Eli Schwartz via arch-general wrote: > On 03/13/2018 12:30 AM, John Ramsden via arch-general wrote: > > Actually, you can easily create an arch ISO with ZFS embedded into > > it. It's what I do, and it takes about five minutes to create. > > > > https://ramsdenj.com/2016/06/23/arch-linux-on-zfs-part-1-embed-zfs-in-archiso.html > > Yes, and it also requires an Arch system (or at least one with pacman > available) to run mkarchiso, pacstrap, copy the initcpio configs from > mkinitcpio, etc. Which is a bit of a chicken-and-egg problem, and I > don't really consider this a viable generic solution... Can't this be done from any distro using Arch rootfs? Cheers, -- Leonid Isaev
Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting
On Mon, Mar 12, 2018 at 11:17:21PM +, Carsten Mattner wrote: > On 3/12/18, Leonid Isaev via arch-general wrote: > > What's wrong with btrfs? Yeah, I know it is not marked "stable", but this > > is just a label. And people shying away from it doesn't help in advancing > > its stability either. > > btrfs never got on my radar because it's Linux only and its instability > is a blocker. If I have to be careful how I use a filesystem even when > I didn't explicitly enable beta features, I'm too scared to put my files > on it. If I were a Suse Enterprise customer, I might use it, but Red Hat > isn't behind it anymore, so it's like Reiser3 back in the day. Only Suse > was putting their weight behind it. Well Facebook has developers on it, > but Facebook isn't a distro developer and can't be trusted with continued > maintenance, since they might switch on a weekend to some Facebook-FS. > Facebook has too many engineers and is reinventing stuff in-house a lot. This is all corporate politics, but see first comment here [1]. And you still haven't explained what instability? I use btrfs on all my machines, including its subvolume/snapshot features to protect against failed updates (essentially, I reimplemented some features of snapper in bash :) because I don't like dbus). Of course, you need to do scrubbing regularly, but it's trivial to write a cron job/systemd timer for this task... > btrfs and zfs suffer from design limitations, but zfs has been stable > and in petabyte production for a long time across many organizations. > btrfs is one of many future Linux filesystems with no clear winner > so far. If noone uses it, then sure, btrfs will remain an underdog of filesystems. Also, if you care about petabyte production, you should know better than asking on this list... > All I want is a modern filesystem whose volume I can share without > exposing it via a network protocol. Hmm, btrfs-send(1)? [1] https://news.ycombinator.com/item?id=14907771 Cheers, -- Leonid Isaev
Re: [arch-general] Update to 4.15.8 on dual quad-core box locked on ( 3/16) Install DKMS modules, need help resurecting
On Mon, Mar 12, 2018 at 10:24:37PM +, Carsten Mattner via arch-general wrote: > On 3/12/18, Eli Schwartz via arch-general wrote: > > On 03/11/2018 10:00 PM, Carsten Mattner via arch-general wrote: > >> I'm happy to hear that. My rationale is based on past observations > >> of needlessly heated arguments and ZFS, due to its license splitting > >> the Linux community in half, appearing to be perfect fuel for such > >> a thread. > >> > >> Thanks for the wiki links. Never used ZFS on Linux because I avoid > >> out of kernel patches. Maybe I will give it a try on Linux as well. > > > > Well yes, the main reason people get heated about it I think is because > > it is out-of-tree kernel modules and as such are less reliably stable or > > some such. > > > > Based on how well archzfs keeps their binary repos up to date, I'm not > > 100% convinced on the stability. Moreso consider that it's difficult to > > bootstrap a system without zfs available, and if their binary repo does > > not match the current archiso... > > I'll stay away from it, thanks. I saw that Alpine Linux has good ZFS > support, but I didn't do anything serious with it. When it comes to > filesystems, I'm conservative, EXT4 and XFS on Linux. It's a pity > there's no modern filesystem to share volumes between FOSS kernels. > It's all some compromise that you might or might not accept. What's wrong with btrfs? Yeah, I know it is not marked "stable", but this is just a label. And people shying away from it doesn't help in advancing its stability either. Cheers, -- Leonid Isaev
Re: [arch-general] systemd permissions on run?
On Fri, Feb 02, 2018 at 11:23:34AM +0800, Oon-Ee Ng via arch-general wrote: > On Fri, Feb 2, 2018 at 9:40 AM, Oon-Ee Ng wrote: > > > Did something change recently w.r.t this? I have smbd, postgresql, and > > squid all failing on me with the following error:- > > > > systemd[1]: smbd.service: Permission denied while opening PID file or > > unsafe symlink chain: /var/run/smbd.pid > > systemd[1]: postgresql.service: Permission denied while opening PID file > > or unsafe symlink chain: /var/lib/postgres/data/postmaster.pid > > systemd[1]: squid.service: Permission denied while opening PID file or > > unsafe symlink chain: /run/squid.pid > > > > The bug tracker only turns u #56966 and #56828 which both have to do with > > the 'nobody' user. > > > > More curiously, this does NOT happen on another Arch laptop I have (with > those same services running). My ls -la results in /run seem to turn up the > same thing, nor are there any differences in shadow/gshadow/passwd etc. Do these seem similar? https://github.com/systemd/systemd/issues/6632 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888976 Cheers, -- Leonid Isaev
Re: [arch-general] Install Archlinux on HP Elitebook
On Sun, Dec 24, 2017 at 07:19:17PM +0100, Ralf Mardorf wrote: > MENU LABEL Ubuntu ^Q LightScribe Rt > LINUX /.boot/ubuntu_q/boot/vmlinuz-3.6.5-rt14 > APPEND root=LABEL=q ro nomodeset > INITRD /.boot/ubuntu_q/boot/initrd.img-3.6.5-rt14 > > LABEL Suse > MENU LABEL ^Vintage SUSE 11.2 Rt What are those ctrl-* characters (like ^Q)? Cheers, -- Leonid Isaev
Re: [arch-general] How to build package in "clean chroot" using the "-U" parameter?
On Fri, Dec 22, 2017 at 02:36:17PM -0300, Giancarlo Razzolini via arch-general wrote: > Em dezembro 22, 2017 13:55 Manuel Reimer escreveu: > > On 12/22/2017 03:17 PM, Giancarlo Razzolini via arch-general wrote: > > I have an existing build system that I call with root permissions and > > from this point on it does everything on its own. Including creating the > > required build user, fetching build dependencies, building packages in > > context of the build user, ... > > > > My idea was to make use of "chroot building" to have a clean state of > > packages for every build. If this is possible, I would add this. If > > fully automated processing doesn't work with the existing tools, I'll > > stick with my way and keep building without chroot. > > > > You keep saying chroot and I guess that arises from the name of the tool, > makechrootpkg. But keep in mind that you don't actually use a chroot, you > use a container. There's a difference, and it's not just semantics. I'm sorry for an unrelated question, but why is it really necessary to make a new container for each pkg? It seems lots of unnecessary copies (I think rsync(1) call in makechrootpkg doesn't do hardlinks)... I understand the issue about getting unlisted deps in packages, but in my experience this problem is minor. So just boot a build container and ssh in there as a non-root user (in fact, you don't even need root inside the container). And keep it clean. At least this has worked for me for years. Also, with newer -ARCH kernels, you can do non-privileged containers, so makechrootpkg should run as a ordinary user to begin with... Cheers, -- Leonid Isaev
Re: [arch-general] Proposal: add "--disable-modern-top" to procps-ng configure flags
On Sat, Dec 09, 2017 at 09:27:49PM -0600, Doug Newgard via arch-general wrote: > On Sun, 10 Dec 2017 00:10:15 + > Jonathon Fernyhough wrote: > > > I submitted, what I thought, was a reasonably structured and detailed > > proposal to change one flag in a PKGBUILD file which would have few (if > > any) side effects. > > > > The whole point of a proposal is to drive a discussion; there is no > > assumption it is absolutely correct. I don't see that as "griping". If > > I'd just said "top sucks, you should fix it", then fine - but I didn't > > do that. > > To be clear, the real issue people are having with you here isn't your > proposal. It's the fact that you submitted it to the bug tracker, the > maintainer saw it, thought about it, and rejected it... In general, discussions about defaults are silly, as long as things are configurable at run-time, so I don't understand why that bugreport was accepted at all... Cheers, -- Leonid Isaev
Re: [arch-general] pacman and journalctl
On Sat, Dec 02, 2017 at 07:15:09AM +, Tom M. wrote: > ha! that was easy, thanks. perhaps manpage needs updating... man pacman.conf says that UseSyslog means "Log action messages through syslog(). This will insert log entries into /var/log/messages or equivalent." It doesn't specify a syslog implementation... Journald is simply one of them. If you wonder about facility and/or priority, then yeah, it is not indicated, but I guess it is daemon/info. Cheers, -- Leonid Isaev
Re: [arch-general] pacman and journalctl
On Fri, Dec 01, 2017 at 11:10:51PM +, Tom M. wrote: > ahoy there! > > is there some cleaver way of making pacman log to journalctl? or plans > to implement such a feature? Uncomment UseSyslog in pacman.conf... -- Leonid Isaev
Re: [arch-general] Server Management Tools
On Thu, Oct 12, 2017 at 09:31:25PM +0200, siefke_lis...@web.de wrote: > On Thu, 12 Oct 2017 18:52:39 + > Giancarlo Razzolini wrote: > > > You seriously consider unattended update of packages on servers a good > > practice? > > On Arch? Good luck with that. > > Who say something from unattended? I want not only set 20 times the same > command. That's all. And writing a bash script that ssh's in and does everything is sooo difficult? If you can't do it, don't update machines automatically. -- Leonid Isaev
Re: [arch-general] Detect broken DHCP setup
On Wed, Sep 06, 2017 at 11:27:13AM +0200, Giovanni Santini via arch-general wrote: > Il 06/09/2017 01:09, Leonid Isaev via arch-general ha scritto: > > > > What does it mean a valid DHCP setup? By reconnection you mean that your > > client > > re-request a lease from the server? Also, dbus has nothing to do with dhcp > > settings... > > I know DBus has nothing to do with DHCP; what I meant is that > NetworkManager shows in its DBus interface when the DHCP configuration > is not valid, so people can reset it. > And almost, what I would do is to restart the connection. But what does it mean "not valid" and "restart connection"? Does it mean that the lease expires and you need to obtain a new one, so you restart NM? Or the system can not reach the network beyond the gateway? > Thanks a lot for the configuration files and the suggestions! If there's > no better solution I can go for them! :) > I still noticed that systemd exposes a DBus network interface > (*org.freedesktop.network1*) which should have proper information but I > found very little documentation online (if none) regarding it... Again, when it comes to network settings, there is nothing to expose over dbus. systemd and NM have this obscure concept of a "system being online" but it is nothing more than a simple ping fedoraproject.org. This test fails in many legitimate cases which makes it useless... Cheers, -- Leonid Isaev
Re: [arch-general] Detect broken DHCP setup
On Wed, Sep 06, 2017 at 12:09:52AM +0200, Giovanni Santini via arch-general wrote: > On that device I am using *systemd-networkd + systemd-resolved* for the > network setup. However, I saw no real method to check if the DHCP > configuration is valid (while NetworkManager provides an element through > DBus inspection). > Does anyone has some knowledge about it? What does it mean a valid DHCP setup? By reconnection you mean that your client re-request a lease from the server? Also, dbus has nothing to do with dhcp settings... In any case, my advice is to get rid of NetworkManager as well as systemd-* tools. If you want a robust dhcp setup on a simple client with a single network card, use dhcpcd (no need even for netctl) because it provides link status detection. But don't use dhcpcd@.service provided with the package, instead replace it with: -> $ cat /etc/systemd/system/dhcpcd\@.service [Unit] Description=dhcpcd on %I Wants=network.target Before=network.target BindsTo=sys-subsystem-net-devices-%i.device After=sys-subsystem-net-devices-%i.device [Service] Type=simple ExecStart=/usr/bin/dhcpcd -4qB -t 0 %I [Install] WantedBy=multi-user.target -< The crucial part is "-Bt 0" which makes dhcpcd wait forever for a lease (read the manpage for other options you might need, for example, in my setup I constrain the demon to only deal with ipv4). My (compatible with read-only root filesystem) /etc/dhcpcd.conf is: -> hostname clientid persistent option rapid_commit option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes option ntp_servers option interface_mtu require dhcp_server_identifier slaac private noipv4ll nohook wpa_supplicant nohook resolv.conf -< these are mostly default settings. Maybe you need to add "nomtu" in case your ISP does something idiotic with this setting (mine does :)). Oh, and hardcode the DNS settings in /etc/resolv.conf, so a broken dhcp server has no control over them. HTH, -- Leonid Isaev
Re: [arch-general] Login Statistics Similar to Centos
On Fri, Sep 01, 2017 at 08:38:24PM +0200, William Gathoye wrote: > > > On 09/01/2017 08:26 PM, brent s. wrote: > > > You don't execute pam_lastlog.so directly. > > > As shown, pam is calling the pam_lastlog.so object (which is why you > > can't execute it; it's not an executable, it's a Shared Object). > > Ok. Actually, I saw this was a shared object, and I wondered this is the > first time was seeing a SO which was executable. This confirms y > assumption :) Most .so files are executable, albeit for historic reasons... And you don't need to directly execute it. The manpage even has EXAMPLES section that explains how to hook pam_lastlog into your PAM setup. You most likely need to call is with some arguments. For instance, on a fedora 26 system: -- : grep pam_lastlog /etc/pam.d/postlogin-ac session [default=1] pam_lastlog.so nowtmp silent session optional pam_lastlog.so silent noupdate showfailed -- Cheers, -- Leonid Isaev
Re: [arch-general] Login Statistics Similar to Centos
On Tue, Aug 29, 2017 at 05:57:46PM -0400, Storm Dragon via arch-general wrote: > Howdy, > I recently was playing with a Centos server. One of the things I found > interesting about the experience is the information presented on login: > > Last login: Tue Aug 29 17:38:48 EDT 2017 on pts/0 > Last failed login: Tue Aug 29 17:47:31 EDT 2017 from 116.31.116.18 on > ssh:notty > There were 37 failed login attempts since the last successful login. > > How can I get Arch to do that same info? I've searched the wiki and forums, > but not found anything. man 8 pam_lastlog Cheers, -- Leonid Isaev
Re: [arch-general] How can I set CAPS LOCK as Escape throughout reboot
On Thu, Aug 17, 2017 at 01:51:59PM +, Junayeed Ahnaf via arch-general wrote: > Hello, > > Currently I use "setxkbmap -option caps:escape" and it works well, but > I'd like to know how to make it persistent through reboot. I set this > line in .xinitrc but it didn't work. It should work. I have a similar line with caps:none in xinitrc and it works. Perhaps smth from your desktop undoes your setting? Cheers, -- Leonid Isaev
Re: [arch-general] New - systemd 234 - luks partition fails to ask for password - workaround
On Mon, Jul 17, 2017 at 07:57:18AM +0200, Bartłomiej Piotrowski wrote: > On 2017-07-17 06:38, SanskritFritz via arch-general wrote: > > On Sat, Jul 15, 2017 at 6:21 PM, Genes Lists via arch-general < > > arch-general@archlinux.org> wrote: > > > >> I have a work around which is to add timeout=90 > >> > > > > Where to add this? > > > > To the kernel parameters, with luks.options= key. Yes, see "man systemd-cryptsetup-generator" and "man cryptsetup" for details. Cheers, -- Leonid Isaev
Re: [arch-general] gnupg: systemd enable in post_install
On Fri, Jun 09, 2017 at 02:24:35PM +0200, Georg wrote: > > > what's the rationale to enable the gnupg sockets in post_install of > > > the > > > package? > > > > > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=packages/gnupg#n21 > > > > > > I don't disagree that the sockets maybe should be enabled (I have them > > > enabled for me), it's just a strange way to enable them in > > > post_install, and linking them in /etc/ > > > > > > Why doesn't the PKGBUILD make the symlinks in > > > /usr/lib/systemd/user/sockets.target.wants/ ? > > > > > > > I did that in the pulseaudio package at first and people complained that > > they couldn't "disable" the pulseaudio socket and "mask" also prevented > > a > > manual start. > > > > Hence I moved pulseaudio from static symlinks to enable/disable > > post_install. > > > > GnuPG follows this. > > > > > > > dbus does that for ex. > > > > > > > The DBus `make install` sets it up that way; it wasn't a downstream > > decision. > > > Packages should never enable or start any services. The same holds for > sockets IMHO. From my point of view the appropriate solution would be a > message in post_install stating the necessity of enabling the > socket/service. There is no such necessity, fwiw. If gpg-agent or dirmngr need to be started, there is .bash_login and such (and dirmng is started by gpg automatically anyways). This dependence on systemd is an abomination because it breaks in so many unpredictable ways. For example, with systemd 233, epiphany freezes when started inside a container and systemd "is looping too fast" (and no, I'm not reporting it upstream), but works if I manually kill systemd --user instance. If you are not using Xorg, "pkill -9 systemd" in .bash_profile saves lots of hair-pulling :) Cheers, -- Leonid Isaev
