Re: Unattended Upgrades question

[likcoras]

On 10/16/18 2:42 PM, john doe wrote:

On 10/16/2018 7:23 AM, Tixy wrote:

On Mon, 2018-10-15 at 21:54 +0100, Brian wrote:

On Mon 15 Oct 2018 at 17:45:36 -0300, rv riveravaldez wrote:

2. If the answer is 'yes': which would be the best/proper way to do
it?


apt purge unattended upgrades




I'll never  understand why being so drastic is a good idea when you can
simply disable it:

https://wiki.debian.org/UnattendedUpgrades

"Below is an example /etc/apt/apt.conf.d/02periodic:
// Control parameters for cron jobs by /etc/cron.daily/apt-compat //


// Enable the update/upgrade script (0=disable)
APT::Periodic::Enable "1";"



I would actually prefer getting rid of it completely instead of having 
it around if I'm never going to use it on the machine. It's not that 
large, but I (personally) try to keep the minimum possible package set 
installed.

Re: iptables config resets after restarting system

[likcoras]

On 08/11/2018 05:29 AM, Hubert Hauser wrote:
> Good afternoon!
> 
> I've problem with resetting iptables after restarting system. Here's my
> /usr/local/bin/fwall-rules file:
> 
> Running command fwall-rules after restarting system works. What am I
> doing wrong?
> 
> --
> Best regards,
> Hubert Hauser.
> 

It seems the firewalls before and after are what you want, according to
your script? There are a few minor differences, but those are the rules
that you specify in the script.

If you're talking about the iptables rules disappearing on reboot,
that's just how iptables works. You need to restore the iptables rules
on every reboot.

There are a few ways to do this. The easiest way would be to install the
iptables-persistent package, which will handle restoring
(ip(6)tables-restore /etc/iptables/rules.v{4,6}) at boot time, or you
could follow the instructions here
.

Also, a few notes about your script:

iptables-save dumps out the current iptables rules into a file.
iptables-apply applies the dump, but in your script, since the rules
have already been set in iptables, there is no need to run
iptables-{apply,restore}.

You probably don't need to maintain a separate script. I'd just maintain
/etc/iptables/rules.v{4,6} and have it be restored by iptables-restore.
That way, I can avoid having to maintain a separate script every time I
want to change my firewall rules.

iptables-apply is used to apply some rules file, then wait for user
confirmation. This makes sure that if your rules block you out of your
ssh session or similar, you don't accidentally make the machine
unreachable by you. In your case, since the rules have already been
applied (you added them in the script), iptables-apply will "undo" the
apply to the previous state, which is already problematic. So there is
no point to using iptables-apply here, since the rules are already
inside iptables.

Re: SystemD problem with launching a server

[likcoras]

On 08/09/2018 08:02 AM, Bill wrote:
> So I've written a service file for systemd,
> /etc/systemd/system/rinetd.service and enabled it with systemctl enable
> /etc/systemd/system/rinetd.service. At boot time the file gets run but
> nothing shows up with ps aux, although sshd is running correctly. I
> think the problem is with the systemd file. Here's the rinetd.service file:
> 
> # /etc/systemd/system/rinetd.service
> # A systemd.service file to start
> # /usr/sbin/rinetd at boot time.
> 
> [Unit]
> Description=Start rinetd server
> After=multi-user.target network.target sshd.service
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/rinetd
> Restart=no
> 
> [Install]
> WantedBy=multi-user.target

I suspect this is because rinetd is forking and not a oneshot script.
You have two choices here: you may use Tye=simple and pass -f to rinetd
(probably recommended, more straightforward to stop the process) or use
Type=forking and leave the rest as-is.

Type=oneshot is used for exactly that, one-shot scripts that are run
once and do not persist. Since rinetd does persist (forks by default),
oneshot is not a good choice here. It wouldn't let you stop the service
through systemd, for instance, even if it worked, without adding
ExecStop manually.

When writing service unit files, I especially find systemd.service(5)
and systemd.exec(5) helpful. Also see systemd.unit(5) for more generic
information on unit files as a whole.

Good luck!

Re: As seen above: use of su vs sudo

[likcoras]

On 08/07/2018 09:06 PM, Joe wrote:
> On Tue, 7 Aug 2018 12:11:50 +0100
> Jonathan Dowland  wrote:
>> If you set a root password in d-i (as it asks you to), it doesn't
>> install sudo. If you try to set a blank root password, it locks the
>> root account, installs sudo and sets up the user you created with sudo
>> access.
>>
> 
> OK, I've never tried that. I always want the option of connecting a
> monitor and actually logging in as root, just in case of
> difficulties. I believe that some boot problems are not solveable
> without being able to provide a root password, long before the
> operating system can provide su or sudo.

In those truly catastrophic cases, you can set init=/bin/sh in the
bootloader kernel line, which will boot you into a root shell.

Re: As seen above: use of su vs sudo

[likcoras]

On 08/07/2018 07:40 PM, Joe wrote:
> On Tue, 7 Aug 2018 11:58:48 +0200
> Why, I don't know, but the last time I installed stable, sudo was not
> installed by default, and never has been in my experience. I always add
> sudo and mc immediately after an installation.

It's installed if you choose to 'disallow login as root' during
installation, which then would prompt you to create a user that will
automatically be given sudo access (by being in the sudo group).

Re: can't install jmtpfs of stretch(i386)

[likcoras]

On 08/05/2018 07:03 PM, Long Wind wrote:
> last time i install security update during stretch installation and can't 
> install mplayer
> 
> this time mplayer can be installed, but jmtpfs can't, below is error msg:

> The following packages have unmet dependencies:
>  jmtpfs : Depends: fuse but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.

Try seeing why apt thinks fuse should not be installed. Not sure how
you'd do this with apt/apt-get, but with aptitude, you can examine
individual packages, their dependencies, and conflicts.

Good luck!

PS. The security updates are most likely not to blame here, methinks.

Re: Warning: Debian/testing full-upgrade removes security packages!

[likcoras]

On 07/15/2018 02:49 PM, Hans wrote:
> be warned: Wheh you do apt full-upgrade, then most security tools, we rely 
> on, 
> are deinstallesd. These are rkhunter, chrootkit, autopsy, tripwire, 
> needrestart and tiger. Also forensics-full and forensics-all are deinstalled 
> (however, this might have other reasons).

Most likely the upgrade is changing packages that are depended on by the
packages you mention. Just re-install them. Just examine which packages
are being changed, see why apt wants to uninstall, and reinstall if needed.

> This is no good behaviour, and it looks for me like the preparation for a 
> global attack on debian. 

The extent of the evidence that supports the idea that this is in fact
an attack on Debian is just that apt is removing these packages on
update. This behavior could be explained by other means, without first
jumping to conclusions about NSA interference.

"Never attribute to malice that which is adequately explained by
stupidity." or, in this case, basically any simpler explanation than
"the preparation for a global attack on debian".

I believe it would have been more helpful if this had been written as a
question on why apt might be removing said packages on upgrade, with
more context, instead of spreading FUD on the list.

Re: Brightness at 100% after every reboot.

[likcoras]

On 06/18/2018 06:33 PM, Piotr wrote:
> On Mon, 18 Jun 2018 17:24:11 +0900
> likcoras  wrote:
> 
>> You may try looking into the systemd-backlight@*.service, see if it's
>> starting properly on your system or if it prints any errors while it
>> starts.
> 
> Strange thing that I see more than one backlight service starting.
> Should I have both of them running? Why do they appear twice in the
> journalctl? Could this be a source of issue?
> 
> Also I do not see the errors in the logs.

This is from the arch wiki[1], it seems the suggestion is to mask one of
the services. On my system, intel_backlight is the only one active and
it works well, so I suggest masking the samsung one with something like:
systemd mask systemd-backlight@backlight\:samsung.service

If that doesn't work, try the other way around, unmask samsung and mask
intel_backlight.

[1] https://wiki.archlinux.org/index.php/Backlight#systemd-backlight_service

Re: Brightness at 100% after every reboot.

[likcoras]

On 06/13/2018 06:53 PM, Piotr wrote:
> Dear all,
> 
> After upgrading to Stretch I have problem with the brightness of my LCD
> screen in laptop. After a reboot of the system I get 100% brightness,
> even if I set it up to like 50%. Where can I change this so the
> settings are preserved between the reboots?
> 
> Regards,
> Piotr
> 

You may try looking into the systemd-backlight@*.service, see if it's
starting properly on your system or if it prints any errors while it starts.

Re: Undesired ssh login attempts

[likcoras]

On 06/10/2018 07:55 PM, deloptes wrote:
> Hi,
> I recently get many of those, which means someone found out that ssh
> external is on port 2 and is trying to do some evil work there.
> Should I worry or do something?

> Similar for apache web server.
> I think both are secure: for ssh no users with easy password allowed to
> login and apache - no pages or stuff that would compromise.
> 
> thanks for opinion
> 
> regards
> 

Welcome to the Internet!

If you're confident of your setup, you can safely ignore them. If you're
 annoyed by the logs, you could set up something like fail2ban to block
connections from IPs that have made too many bad attempts (although this
could possibly be used to lock you out).

My recommendation is the same as Dan's, consider disabling password
login to allow only pubkey authentication. Same with the ports, I
usually don't bother with using a non-standard port since it would, at
best, only reduce the volume of attacks and not really provide any
additional security.

Same with apache, if you think your server is secure, just let it be;
there's nothing you can do, really. Maybe put your server behind some
service that stops automated/malicious access (eg. CF) if you're into
that kind of thing, I guess?

Good luck!

Re: Debian 9 x64 wine32

[likcoras]

On 06/05/2018 03:57 AM, --- wrote:
> What i did:
> 
> Starting off with: apt install wine32
> 
> Reading the messages, adding libwine:i386 and tried "apt install" again
> 
> Reading again etc. adding step by step all requested (not suggested)
> packages.
> 
> So all in all i entered:
> 
> apt install wine32 libwine:i386 libglu1-mesa:i386 libldap-2.4-2:i386
> libpulse0:i386 libgl1-mesa-glx:i386 libdbus-1-3:i386 libsystemd0:i386
> libdrm2:i386

Huh, is apt not able to resolve those dependencies? aptitude handled
them for me just fine... Or not. Been a while since I installed wine on
this system, and I might have done some manual dependency resolution
with aptitude, can't recall.

> WARNING: Following packages will be removed . . . .
>   bsdutils libsystemd0 (wegen bsdutils) init systemd-sysv (wegen init)
> sysvinit-utils
>   util-linux (wegen sysvinit-utils)

Anyways, the problem's here, none of these packages are supposed to be
removed when installing wine.

Looking at libsystemd0, it has a few "breaks" relations to other
versions of libsystemd0 (on my system, libsystemd0:i386 !=
232-25+deb9u3) and I'm assuming apt is trying to install one of those
"bad" versions. Since you've explicitly stated that you want to install
libsystemd0:i386, apt decided that removing libsystemd0:amd64 is the
only option.

Not exactly sure how to do this with apt, but when I've had similar
issues from time to time when installing wine on other systems, I just
resolved dependencies manually using aptitude. It can be a bit
burdensome, but should work once you select the proper versions of core
packages so that they do not conflict with existing system packages, and
then let aptitude do the rest of the resolution for you.

That's the reason I still use aptitude, sometimes I really need to
manually resolve dependencies in order to avoid pulling in those bad
packages.

Good luck!

Re: Debian 9 x64 wine32

[likcoras]

On 06/02/2018 08:06 PM, uli...@web.de wrote:
> i am trying to install wine32 on a amd64 debian stretch system.

> Using apt-get the package "wine32" is known, but needs libwine:i386.
> 
> Trying to install all dependencies results in a possible complete chnage of 
> the 
> system-packages, which i have interrupted.

What do you mean by a "complete change of system-packages"? If you mean
that libwine:i386 pulls in a lot of :i386 libraries, that's to be
expected, as it needs all of its dependencies in i386. I don't remember
it ever replacing my packages.

If you mean that it's somehow replacing existing packages, try posting
what kind of changes apt-get is suggesting, so we can get a better view
of what's going on in your system.

As for the synaptic thing, no idea, I've never used it. Hopefully
someone else around here knows.

Re: Usability BUG - Which package appropriate?

[likcoras]

On 05/29/2018 05:03 AM, Richard Owlett wrote:
>>> *HOWEVER!*
>>> The first line stated "Emacs 26.1 is out, download it here!"
>>> Bu [https://packages.debian.org/stretch/emacs] refers to
>>> "Package: emacs (46.1)".
>>
>> And goes onto say that it's a metapackage that depends on emacs24; so,
>> in true Debian fashion, they're on what they consider to be "stable",
>> even if it means it's a few versions behind.
> 
> BOTHER to read links?
> Debian claims to be *20* MAJOR  releases *AHEAD* of source.

Adding to what David wrote, the description for (meta-)package emacs
reads as follows:

Description: GNU Emacs editor (metapackage)
 GNU Emacs is the extensible self-documenting text editor. This is a
metapackage that will always depend on the latest recommended Emacs release.

Taking a look at the dependencies of this metapackage, they are as follows:

Depends: emacs24 | emacs24-lucid | emacs24-nox

Now, looking at the emacs24 package, it seems to have all the relevant
information.

Package: emacs24
Version: 24.5+1-11+deb9u1
[...]
Description: GNU Emacs editor (with GTK+ GUI support)
[...]
Homepage: http://www.gnu.org/software/emacs/

I haven't really noticed that any packages missing their homepages (if
they exist). Moreover, most packages already include their own
documentation (or have a -doc package) which can usually answer whatever
question you might want answered from the webpage, right on your local
system!

As an aside, please avoid being hostile in the mailing list. People are
often just trying to help, no need to snap at them. :)

Re: rsync error -- "Protocol incompatibility" Why?

[likcoras]

On 05/28/2018 09:07 PM, Richard Owlett wrote:
> I had used rsync to back up a different partition with no problems.
> 
> I used that command as a model to attempt to backup another partition.
> 
>> root@debian-jan13:~# root@debian-jan13:~# rsync --verbose  --progress
>> --stats --recursive --times --perms --links
>> /media/root/drescued_commo/  /media/root/backups/drescued_commo/
>> sending incremental file list
>> rsync: change_dir "/media/root/drescued_commo" failed: No such file or
>> directory (2)
> 
> I then checked for existence of source:
> 
>> root@debian-jan13:~# ls /media/root
>> 17oct2017   debian64  rco sda14.bak
>> backups gddrescued_commo  rco1    sd-card
>> common  good-fvwm recover-common  stretch-2nd
>> common-bak  jessie8-6-sda6    sci-fi-dvds tomboy-testing
>> root@debian-jan13:~# 

Are you sure it's not a typo? I can't see "/media/root/drescued_commo/",
only "/media/root/gddrescued_commo"...

Re: Get the external IP address from a Linux box

[likcoras]

On 05/24/2018 03:48 PM, John Conover wrote:
> =?ISO-8859-1?Q?Andr=E9?= Rodier writes:
>>
>> I am looking for a native package on Debian, that can give me the
>> external IP address of the machine.
>>
> 
> Hi Andre.
> 
> Type "ifconfig" without the quotes. The record you are looking for is
> inet addr: for IPV4. Its about the second line from the top.
> 
> John
> 

ifconfig would only work if you are directly assigned the public,
external IP. If you are behind eg. a router that does NAT, you would
only see the private IP internal to the local network.

I am not aware of any packages in the repos that has this kind of
functionality, but you could always just write a simple script around
the various sites that report your external ip.

It can be as simple as `curl ipinfo.io` (or your preferred site), you
could even try to have a script to try a few backups in case your
primary site happens to be unreachable.

Re: Emails

[likcoras]

On 05/09/2018 09:01 PM, David wrote:
> I currently use Evolution for my emails with Debian 8.
> 
> The version in the repository is very old, I'm currently using V3.12.
> 
> Is there a method for me to access a repository with a newer version?
> 
> regards,
> 
> David.
> 
> 

It is generally not recommended to install software yourself unless you
know what you're doing. You do have a few choices:

1. Update to Debian Jessie (9). This will get you evolution 3.22.6.
2. Update to Debian Buster (testing), currently 3.28.1, if you don't
mind running testing. Make sure you are ready to run testing, though.
3. Grab a copy of the evolution source code from
 and compile it yourself (a-la
make; make install). Make sure this is what you want, and that you are
aware of the consequences of going down this path.
4. Backport evolution yourself. I personally have never done something
like this, so not 100% sure on the procedure involved. I assume it might
be safer than doing the 'make install' as in (3).

Overall,  is good resource to
refer to in case you want to do something like this, make sure that you
know what you're doing and what can happen to your system if you do it.
Especially pay attention to
.

Most importantly, determine if you actually do need the newer version in
the first place, or if you're upgrading just for the sake of upgrading.
The Debian developers are quite good at keeping up to date with security
updates, so hopefully you won't need to worry about those too much.

Re: How does "making VPN accessible" works?

[likcoras]

On 05/09/2018 05:37 AM, Yuri Kanivetsky wrote:
> To investigate I added the following rules to iptables:
> 
> iptables -A INPUT -p tcp --dport 443 -j LOG
> iptables -A OUTPUT -p tcp --sport 443 -j LOG
> 

> While it was running, I ran a https request to the server from my
> local computer. It hang, I waited for a while, then interrupted it. It
> didn't reach nginx running on the server, and there where no entries
> from iptables in systemd journal.

> Then, I found another solution
> (https://unix.stackexchange.com/questions/182220/route-everything-through-vpn-except-ssh-on-port-22/242808#242808).
> I undid the four commands above and ran:
> 
> ip rule add table 128 from eth0.ip
> ip route add table 128 default via eth0.gw
> 
> This time it worked. And I saw log entries from iptables in systemd journal.
> 
> My understanding is that before tinkering with iptables and routing
> table, packets from my computer arrived to the server, but the ones
> coming back were routed via VPN server's gateway (tun0.gw). There they
> were probably NAT'ed (different source IP), and as such were not
> recognized as a response by my local computer. But why then were there
> no entries from iptables in systemd journal?
> 
> The last solution supposedly made packets return via hoster's default
> gateway (eth0.gw). But when I do "traceroute 8.8.8.8", I see them
> going via tun0.gw. And "curl -sS ipinfo.io/ip" returns my VPN server's
> public IP. So, some packets are going via eth0.gw, some via tun0.gw.

>From what I can understand, the last set of commands made responses to
packets entering the server from its public interface will always leave
through the public interface. Since your regular traffic (not originally
intended to be sent to the server, only routed through) are not received
through the public interface, but through tun0, they are not affected by
the above rule and do whatever they were doing before you ran the above
commands.

> How does it decide? This is routing table before connecting to VPN
> server:
> 
> default via eth0.gw dev eth0 onlink
> eth0.subnet/25 dev eth0  proto kernel  scope link  src eth0.ip
> 
> This is what VPN server added:
> 
> vpn.server.ip via def.gw dev eth0
> tun0.subnet/24 dev tun0  proto kernel  scope link  src tun0.ip
> 0.0.0.0/1 via tun0.gw dev tun0
> 128.0.0.0/1 via tun0.gw dev tun0

It's quite weird that return packets were being routed via the vpn in
the first place. I don't think I've had to do any special setup on my
VPN server to achieve what you've done here. What you describe should be
the default behavior, not something that requires extra configuration.

On my setup, all connections except those that go to the vpn server's
public IP are routed through the vpn. If I were to connect to the server
ip from my local machine, it will just exit and reach the server like a
normal connection, not going through any VPN, and the server, seeing
that the connection came in through its public interface, has no reason
to route the response through another interface.

>From the routing table shown above, you have the same setup on the
client side, connections to vpn.server.ip are sent through eth0, others
(0.0.0.0/1 and 128.0.0.0/1) are sent through the vpn.

If a https request from the client never reached the server, there might
be some other issue somewhere else in your setup. Might be useful to see
iptables-save output from both sides of the connection, client and server.

My setup, for reference:

client:
No particular setup on the firewall, just a regular filtering firewall.
routes:
# Route the rest of the traffic through the VPN tunnel
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0
# Route VPN traffic through the VPN tunnel
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
# Bypass vpn for direct connections to server (avoid routing loops)
{server ip} via 192.168.0.1 dev wlx88366cf24c67
# Defaults used before vpn/local network.
default via 192.168.0.1 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2
server:
firewall has these extra lines:
# NAT so client packets routed through the server seem to be coming from
# the server ip.
-A POSTROUTING -s 10.8.0.0/24 -o enp0s20 -j SNAT --to-source {server ip}
# allow incoming vpn traffic
-A udp -p udp -m udp --dport 1194 -j ACCEPT
# Allow forwarding tun0 traffic through the public interface
-A FORWARD -i tun0 -o enp0s20 -m conntrack --ctstate NEW -j ACCEPT

routes:
default via {server ip} dev enp0s20
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
{server net}/24 dev enp0s20 proto kernel scope link src {server ip}

Plus the sysctl net.ipv4.ip_forward=1.

This seems to be the setup that makes the most sense (to me), and what
seems to be default behavior of openvpn. Try to see if there's some part
in your setup before running those extra commands that is significantly
different from mine.

> These lines seem like they should route most if not all packets
> originating from the 

Re: can't access debian no more

[likcoras]

On 04/10/2018 10:21 PM, mess-mate wrote:
> Hi,
> after an install of windows 10 (need it some a progran can't run on linux),
> somewhat seems to be changed on the hd.
> The startup lock on the disk control/fs.
> regards
> 

Usually the suggestion on installing both Debian and Windows is to
install Windows first, since it has a tendency to ignore other operating
systems on the disk and overwriting the bootloader with its own, which
is what I think has happened here.

Try reinstalling the Debian bootloader as suggested in the other reply,
see if that works. Grub is decent at detecting other operating systems
and should avoid breaking boot.

Re: Chaniging focus: security ouitside a password manager

[likcoras]

On 04/02/2018 10:07 PM, rhkra...@gmail.com wrote:
>* during copy and paste operations, the plaintext password could remain on 
> the C "stack". thus making it vulnurable:  Some notes:

This is a semi-valid concern, depends on your usage patterns. For
example, some browsers may expose a JS API that allows sites to read
your clipboard. Adobe Flash has a similar feature, IIRC.

Also, other applications running on your desktop may be able to read the
clipboard contents as well, but that would require user privileges on
your machine. Take that into account when deciding whether this is
something you need to be worried about.

>   (1) I've read about at least one password manager that, somehow, 
> deletes 
> the plaintext password from the copy and paste "stack" after a time delay--I 
> didn't make a note of which one that was.  

I'm sure this is a relatively common feature in password manages. pass,
for example, has this feature. That's quite something, considering how
minimalistic it is compared to other, more fully-featured password
managers out there. It does just use xclip(1), though.

>From pass(1):

show [ --clip, -c ] pass-name
   Decrypt  and print a password named pass-name. If --clip
   or -c is  specified,  do  not  print  the  password  but
   instead  copy  the  first  line  to  the clipboard using
   xclip(1) and then restore the  clipboard  after  45  (or
   PASSWORD_STORE_CLIP_TIME) seconds.

>   (2) another approach could be that a password manager provides a 
> facility to write the password to a designated textbox without using the copy 
> and paste facility, thus, presumably, never putting the plaintext password on 
> the copy and paste "stack").

pass also has this feature, suggesting it is a common feature to may
password managers. Through a third-party script (available in contrib/
on the git repo, or /usr/share/doc/pass/examples/dmenu/ after
installation on debian), this is possible. It basically just makes a
call to xdotool(1) and passes in the password to be typed. xdotool
handles the actual typing. As a plus, works even when sites decide to
block c Obviously, you could use some other front-end, or write one
yourself.

>* during hibernation (or maybe suspend and resume): (I use neither at the 
> present time, but, one stores the machine's state (including RAM) to disk, 
> the 
> other stores the (CPU) state to RAM while preserving the other contents of 
> RAM.)  Hibernation could result in the plaintext of passwords being stored on 
> disk while the power is off, making the plaintext passwords vulnurable if the 
> machine is stolen.

As Tomás said, make sure your swap partition is encrypted, if you bother
with disk encryption. Even when not hibernating, if you start swapping,
you may be storing valuable information in there without you knowing.
It's usually a Bad Idea to have a plaintext swap but encrypted data
partitions.

Moreover, proper crypto code would probably make sure to remove keys
from memory as quickly as possible, as soon as they're no longer
necessary. No idea if GPG does this, though. Might be worth looking into.

Re: Password Manager opinions and recommendations

[likcoras]

On 03/26/2018 12:52 AM, rhkra...@gmail.com wrote:
> I started reading up on password managers in order to consider using one.  

Good! Welcome aboard.

> Here are some of what I think are my criteria for a password manager:
> 
>* encrypted storage on my own machines (no storage "in the cloud")
>* ability to transfer to other devices, including Android tablets and 
> phones--either all the passwords or just one for some special logon on a 
> machine I don't normally use.  Currently I do almost everything (that 
> requires 
> a password) on one of my desktop computers.  I have a laptop that I use very 
> occasionally.  Occasionally I've had to go to a library (or similar) to use a 
> Windows machine.  I do have an Android tablet and phone, and, in general, I 
> don't use that for confidential type stuff (no banking, for example), but 
> that 
> could change if either I feel very secure or in some sort of extreme 
> emergency.
>* (a repeat of part of the previous bullet) a means to easily take an 
> individual password to another machine for occasional use of another machine 
>* a means to recover all the passwords if the password manager becomes 
> defunct (and this also implies backup and restore capabilities)
>* a means to automatically generate secure passwords
>* a means to automatically update passwords on the target websites (to 
> facilitate regular / frequent password changes)--this is probably a 
> stretch--I 
> mean something that would work its way through the various screens and 
> prompts 
> to change a password with a minimum of manual intervention by me
> 

I think pass (https://www.passwordstore.org/) meets most of your
requirements. It's a glorified shell script that calls gpg under the
hood to create passwords that are stored locally (under ~/.password-store).

- It does not have a network component.
- You can transfer individual password files, decrypt them yourself with
gpg, etc.
- Very straightforward to decrypt with a simple shell script.
- Uses pwgen to generate passwords, if requested. You can customize
generation a bit (no special characters, etc.)
- It does not handle automatic password updates.

It would also be trivial to modify the script to use some other password
generator, and of course you can input your own passwords.

The pass package in Debian also includes the passmenu utility, which
uses dmenu to automatically type in your password for you. I highly
recommend you use this or some other frontend, as copy-pasting passwords
becomes a chore. Let the password manager type it out for you!

That is one disadvantage of pass, though. It does not have a built-in
frontend, so it requires you to install some other piece if you want to
use it more efficiently.

Also note, if you decide to use passmenu, I think there was some bug
where it did not properly escape text when typing it in for you. Not
sure if it was patched or if the bug is still open. If it gives you
trouble, just grab the latest version from the pass git repository.

> As an alternative to a password manager, I may create my own memorizable 
> password generator "algorithm" that I can mostly use "in my head".  For 
> instance, it could be something like this:
>* think up a multiword phrase, possibly with a mnemonic connection to the 
> target website (or, have a means to extract them from a book, e.g., the 3rd 
> sentence of the 5th chapter of War and Peace--or maybe the first sentence in 
> the book that contains the word bank would become the passphrase for my bank).
>* have a consistent substitution algorithm, which might do things like 
> this:
>   * capitalize the nth letter of each word (or the nth letter of the 
> first 
> word, the (n+1)th letter of the 2nd word, ...
>   * substitute (or insert) a punctuation mark for (like above) the mth 
> letter of each word (or the mth letter of the first word, the (m+1)th letter 
> of 
> the 2nd word, ... --the puntuation might be selected in, for example, 
> keyboard 
> order (or reverse keyboard order) across the numeric keys (e.g., !@#$%^&*() 
> (although maybe some of those might be invalid in (some?) passwords)
>   * some other similar generation rules
> 
> Obviously, having "published" these ideas, my actual implementation will be 
> somewhat different ;-)   

About that, I would suggest you just use diceware
(http://world.std.com/%7Ereinhold/diceware.html). The page includes
instructions on adding special characters/etc to increase
entropy/satisfy dumb requirements.

The reason for this is that you are guaranteed  a certain amount of
entropy even if your method of generating passwords is revealed, even if
they know which wordlist that you use.

Something like what you describe might possibly be safer, but you can't
really quantify how much security you would be giving up by omitting
some step, or how worried you should be about having some of the steps
revealed by accident or by other, more nefarious means. Don't take

Re: GPG key expiry questions?

[likcoras]

On 03/14/2018 09:14 PM, Daniel Bareiro wrote:
> On 14/03/18 03:26, Ansgar Burchardt wrote:
>> Just run `gpg --refresh-keys` from time to time.
> 
> Thanks for the suggestion. I have updated my keyring:
> 
> GNUPG seems to have found 9 new signatures ('firmas' in spanish)  from
> Richard.
> 
> The output in English would be something like this:
> 
> Total amount processed: 193
> without changes: 196
> new identifiers: 14
> new subkeys: 14
> new signatures: 3201
> 
> These 'signatures' are new public keys?
> 
> Still Thunderbird is showing the expired key. Should I restart it to
> take the changes?
> 

The "identifiers" (UIDs) are the new identities (name-email pairs) added
to keys by the key owners.

Subkeys are just subkeys, added by the key owners. These are more like
the new public keys, not the signature count below.

Signatures are published signatures on the key in question, not just the
self-signatures but by other keys as well. In this case, most probably 9
other people signed the key, and the signatures were published to the
keyserver. Not selfsigs, those are less common.

Enigmail just runs gpg(2) under the hood, so if gpg reports the correct
results, a restart should be enough, unless it has a separate cache for
some reason.

Re: GPG key expiry questions?

[likcoras]

On 03/14/2018 11:39 AM, Richard Hector wrote:
> And if I search for my key here:
> 
> https://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xb4a2f08fec70168d
> 
> ... I can see that there is a self-sig with the expiry date Daniel
> mentioned, but also one for the one I'm seeing.

You can change the expiry date of your own key, but for other people to
be able to see it and avoid having your key show up as expired, you must
publish the new (key? signature? not sure...) and others must fetch it
before the expiry date hits.

I think what happened is that you edited the expiration date of your key
and published it, but the other person didn't get the updated version
before their copy of your key expired.

Re: i3 wm sound volume and brightness

[likcoras]

On 02/10/2018 04:20 AM, Robert Ford wrote:
> My i3 config for sound volume and brightness is 
> https://paste.debian.net/1009555
> 
> The problem is configuration for sound works but there is no display. And for 
> brightness, xbacklight -inc N or xbacklight -dec N returns message
> 
> No outputs have backlight property
> 
> I read that's because xbacklight can't find the corresponded backlight in 
> /sys/class. I am aware that changing the value at 
> /sys/class/backlight/intel_backlight works, but I am looking for somewhat 
> more portable way.

I'm not sure on the sound issue, but I remember having the same exact
issue when I was setting up my current system. From what I can recall,
it involved changing some setting in the xorg configuration.
Specifically adding the Driver line (as below).

# /etc/X11/xorg.conf.d/10-display.conf:
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "UXA"
EndSection

Try adding this file (not sure if the UXA line was necessary), restart
X, and see if it fixes the issue with xbacklight.

Re: 404 trying to use stretch/backports

[likcoras]

On 01/11/2018 04:08 PM, Felix Miata wrote:
> ...
> err:9 http://ftp.debian.org/debian stretch-backports/main i386 Packages
>   404  Not Found...

Try adding a trailing slash to the deb url:

http://ftp.debian.org/debian/
and not
http://ftp.debian.org/debian

Re: libapache2-mod-speedycgi debian jessie

[likcoras]

On 11/29/2017 08:42 AM, Frederic Robert wrote:
> Hello,
> 
> How are you? i don't find libapache2-mod-speedycgi in jessie. Only for 
> Wheezy. What is this name in Jessie?
> 
> Thank you for your help,
> 

It was removed after wheezy, it seems. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707335