Re: Why does this take so much time?
Le 23-04-2022, à 17:01:22 +0100, Eric S Fraga a écrit : On Friday, 22 Apr 2022 at 19:37, Charles Curley wrote: I was in a position to help, so I did. I have not so far heard back from Steve whether he has found a solution. Just to add a data point, probably mostly for the benefit of the OP: I use Signal and have the same source in my list for apt and have no problems at all. I've noticed no delay for that server. Just tried updating right now and the response was immediate. Thanks Eric for that. So it's on my side, which is good to know. And I just noticed that it happens on my main machine and not on my laptop.
Re: Why does this take so much time?
On Friday, 22 Apr 2022 at 19:37, Charles Curley wrote: > I was in a position to help, so I did. I have not so far heard back > from Steve whether he has found a solution. Just to add a data point, probably mostly for the benefit of the OP: I use Signal and have the same source in my list for apt and have no problems at all. I've noticed no delay for that server. Just tried updating right now and the response was immediate. -- Eric S Fraga with org 9.5.3 in Emacs 29.0.50 on Debian 11.3
Re: Why does this take so much time?
Le 23-04-2022, à 07:13:32 -0600, Charles Curley a écrit : On Sat, 23 Apr 2022 11:06:29 +0200 steve wrote: cat signal-xenial.list deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main The keyring thing missing was I added it, but it didn't change anything, update still lags. But upgrade goes quickly. OK, just an idea. Are you going through any proxy server, such as apt-cacher-ng? apt-cacher-ng doesn't like https at all and that could be part of the problem. Na, nothing like that.
Re: Why does this take so much time?
On Sat, 23 Apr 2022 11:06:29 +0200 steve wrote: > cat signal-xenial.list > deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main > > The keyring thing missing was I added it, but it didn't change > anything, update still lags. But upgrade goes quickly. OK, just an idea. Are you going through any proxy server, such as apt-cacher-ng? apt-cacher-ng doesn't like https at all and that could be part of the problem. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Why does this take so much time?
Hi, Thanks to everyone for the help, and I know I'm a bit off topic here with this Signal thing, sorry. It's the only Franken thing on my box. But, I thought maybe someone was also using Signal on their Debian box and could help. In fact this lag when updating in pretty new, but I cannot say when it appeared in the first place (thought it might go away by it's own). Le 22-04-2022, à 12:11:14 -0600, Charles Curley a écrit : On Fri, 22 Apr 2022 19:26:47 +0200 steve wrote: When I 'apt update', the following URL takes ages: Atteint :2 https://updates.signal.org/desktop/apt xenial InRelease Why? Do you see the same? As luck would have it, I just had an update for signal (5.40) waiting for me. I saw no noticeable delay. What is your sources.list for signal? I have: root@hawk:~# cat /etc/apt/sources.list.d/signal-xenial.list deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main cat signal-xenial.list deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main The keyring thing missing was I added it, but it didn't change anything, update still lags. But upgrade goes quickly. Is there a debug mode for apt that could be helpful? I tried apt -oDebug::pkgAcquire::Worker=1 update but it doesn't show interesting info for my case. Might need to fire up tcpdump to see the trafic.
Re: Why does this take so much time?
On Fri, 22 Apr 2022 18:46:39 + "Andrew M.A. Cater" wrote: > Thanks for stepping in with concrete help - it's good that we had > someone else running Signal to help. I was in a position to help, so I did. I have not so far heard back from Steve whether he has found a solution. > I think the point I wanted to make is that we _can't_ be expected to > help out on all third party .debs, especially when that .deb is > compiled against an obsolescent version of Ubuntu. Likewise "I'm > running Linux Mint / TDE and I can't find support in their channel - > please help" I agree, people should not expect help on 3rd party applications, frankendebians, or other situations that run against the standard advice around here. I think you did a good job of explaining this to Steve. Once in a while, someone asks for help in such a situation, and someone else is in a position to give it. But that's the exception. So I have no problem with someone asking. I do take exception to some twatwaffle getting irate because no-one answered his badly framed and off-topic query. Besides, we're all volunteers here, something some people can't seem to get wedged between their ears. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Why does this take so much time?
On Fri, Apr 22, 2022 at 12:17:27PM -0600, Charles Curley wrote: > On Fri, 22 Apr 2022 17:48:06 + > "Andrew M.A. Cater" wrote: > > > Mixing .deb packages from multiple Debian/Debian-derived > > distributions is normally a very bad idea - > > https://wiki.debian.org/DontBreakDebian > > In general I agree with this. However, this is what the signal folks > tell Debian users to do. So if they answer Steve at all, that is likely > what they will tell him to do. > Hi Charles, Thanks for stepping in with concrete help - it's good that we had someone else running Signal to help. I think the point I wanted to make is that we _can't_ be expected to help out on all third party .debs, especially when that .deb is compiled against an obsolescent version of Ubuntu. Likewise "I'm running Linux Mint / TDE and I can't find support in their channel - please help" A large chunk of the mails here are sorting out: "I don't know how to edit an /etc/apt/sources.list" or "I added some app from some site and it all broke" or "I mixed Ubuntu and Debian and now I don't know what I have" Those are almost as popular as the favourite: "I did something, then I did something else then X happened so I did Y and now it's not working but I've no idea how I got here" which is a well known thread starter here. With every good wish, as ever, Andy Cater
Re: Why does this take so much time?
On Fri, 22 Apr 2022 17:48:06 + "Andrew M.A. Cater" wrote: > Mixing .deb packages from multiple Debian/Debian-derived > distributions is normally a very bad idea - > https://wiki.debian.org/DontBreakDebian In general I agree with this. However, this is what the signal folks tell Debian users to do. So if they answer Steve at all, that is likely what they will tell him to do. root@hawk:~# apt show signal-desktop Package: signal-desktop Version: 5.40.0 Priority: optional Section: default Maintainer: Signal Messenger, LLC Installed-Size: 375 MB Depends: libnotify4, libxtst6, libnss3, libasound2, libxss1 Recommends: libappindicator3-1 Homepage: https://github.com/signalapp/Signal-Desktop#readme Vendor: Signal Messenger, LLC License: AGPL-3.0-only Download-Size: 116 MB APT-Manual-Installed: yes APT-Sources: https://updates.signal.org/desktop/apt xenial/main amd64 Packages Description: Private messaging from your desktop N: There are 43 additional records. Please use the '-a' switch to see them. root@hawk:~# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Why does this take so much time?
On Fri, 22 Apr 2022 19:26:47 +0200 steve wrote: > When I 'apt update', the following URL takes ages: > > Atteint :2 https://updates.signal.org/desktop/apt xenial InRelease > > Why? Do you see the same? As luck would have it, I just had an update for signal (5.40) waiting for me. I saw no noticeable delay. What is your sources.list for signal? I have: root@hawk:~# cat /etc/apt/sources.list.d/signal-xenial.list deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main root@hawk:~# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Why does this take so much time?
On Fri, Apr 22, 2022 at 07:26:47PM +0200, steve wrote: > > Hi, > > > When I 'apt update', the following URL takes ages: > > Atteint :2 https://updates.signal.org/desktop/apt xenial InRelease > > Why? Do you see the same? > > Best, > > s > Hi steve, Sorry: This is a third party .deb package which appears to be packaged for an Ubuntu release 16.04 (Xenial Xerus) that is now out of standard support from Canonical with effect from the release of Jammy Jellyfish yesterday. I'm not sure we can help you on this list and I would suggest that you ask signal.org. Mixing .deb packages from multiple Debian/Debian-derived distributions is normally a very bad idea - https://wiki.debian.org/DontBreakDebian With every good wish, as ever, Andy Cater
Re: Why does GNOME take so much time to tell that a screensaver-introduced password is erroneous?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Owens row...@ptd.net writes: On Mon, Jun 21, 2010 at 05:07:33PM -0500, Ron Johnson wrote: On 06/21/2010 04:47 PM, Celejar wrote: On Mon, 21 Jun 2010 23:35:37 +0200 Merciadri Lucaluca.mercia...@student.ulg.ac.be wrote: Hi, I use GNOME. I have noticed that if I type some erroneous password to leave the screensaver mode, GNOME takes ~3 or 4 secs. to tell me that it is erroneous. If I type the correct password, I am directly sent in my session. Why does it take so much time to tell me that a password is erroneous? I can even know if I made a typo by looking at how much time it takes! Same thing with xscreensaver. I think that a lot of software that asks for a password behaves like this, perhaps to prevent brute-forcing? I'm not sure if brute-forcing is possible on a GUI, though. Since I notice the same issue when logging in from the console, could it be a problem with libpam? /etc/pam.d/login contains this on my system: # Enforce a minimal delay in case of failure (in microseconds). # (Replaces the `FAIL_DELAY' setting from login.defs) # Note that other modules may require another minimal delay. (for # example, # to disable any delay, you should add the nodelay option to pam_unix) auth optional pam_faildelay.so delay=300 Thanks for mentioning this. - -- Merciadri Luca See http://www.student.montefiore.ulg.ac.be/~merciadri/ - -- The whole dignity of man lies in the power of thought. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkwmOuEACgkQM0LLzLt8MhwS7QCeMbeR0SW3LzNczvEw5Pltjz+I 5IwAoIjQrWQHw9j4whMUgVjzwnOmXh3g =X2nu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vd95elum@merciadriluca-station.merciadriluca
Re: Why does GNOME take so much time to tell that a screensaver-introduced password is erroneous?
On Mon, Jun 21, 2010 at 05:07:33PM -0500, Ron Johnson wrote: On 06/21/2010 04:47 PM, Celejar wrote: On Mon, 21 Jun 2010 23:35:37 +0200 Merciadri Lucaluca.mercia...@student.ulg.ac.be wrote: Hi, I use GNOME. I have noticed that if I type some erroneous password to leave the screensaver mode, GNOME takes ~3 or 4 secs. to tell me that it is erroneous. If I type the correct password, I am directly sent in my session. Why does it take so much time to tell me that a password is erroneous? I can even know if I made a typo by looking at how much time it takes! Same thing with xscreensaver. I think that a lot of software that asks for a password behaves like this, perhaps to prevent brute-forcing? I'm not sure if brute-forcing is possible on a GUI, though. Since I notice the same issue when logging in from the console, could it be a problem with libpam? /etc/pam.d/login contains this on my system: # Enforce a minimal delay in case of failure (in microseconds). # (Replaces the `FAIL_DELAY' setting from login.defs) # Note that other modules may require another minimal delay. (for # example, # to disable any delay, you should add the nodelay option to pam_unix) auth optional pam_faildelay.so delay=300 -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623213257.ga13...@aurora.owens.net
Re: Why does GNOME take so much time to tell that a screensaver-introduced password is erroneous?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl E. Jorgensen k...@fizzback.net writes: Hi! On Mon, Jun 21, 2010 at 05:47:21PM -0400, Celejar wrote: On Mon, 21 Jun 2010 23:35:37 +0200 Merciadri Luca luca.mercia...@student.ulg.ac.be wrote: I use GNOME. I have noticed that if I type some erroneous password to leave the screensaver mode, GNOME takes ~3 or 4 secs. to tell me that it is erroneous. If I type the correct password, I am directly sent in my session. Why does it take so much time to tell me that a password is erroneous? I can even know if I made a typo by looking at how much time it takes! I believe that artificially introducing a delay when wrong credentials are presented is standard operating procedure for most things where a password must be entered. As far as I know, there are several rationales behind this: - To frustrate anybody trying to guess passwords. Being allowed to try many combinations in a short time helps make things difficult for attackers, and does not help legitimate users. - To avoid leaking information: If entering a nearly-correct password responds faster than when entering an obviously-wrong password, an attacker can use this to improve the guesses - sort of triangulating. If it always takes the same amount of time before the wrong username/password reply comes, this information is not available to a prospective attacker. I presume that some implementations add a random delay to obfuscate things further. All in all, this makes things more difficult for attackers, whilst only being a minor inconvenience for the good guys: a good trade-off. Same thing with xscreensaver. I think that a lot of software that asks for a password behaves like this, perhaps to prevent brute-forcing? I'm not sure if brute-forcing is possible on a GUI, though. I suspect this is simply a problem of aquiring the right tools for the job: - X events can be generated by software (e.g. the xmacro package). This is evident if you use VNC to control a remote machine: the screen saver is none-the-wiser to the fact that you are remote. - USB keyboards can probably be simulated by other devices. I would not be surprised to find linux tools that allow a PC to act as a USB device, rather than USB master. From here on, it is just software again. and probably lots of other ways... Thanks (to others too). - -- Merciadri Luca See http://www.student.montefiore.ulg.ac.be/~merciadri/ - -- Remember. If something can go wrong, it will. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkwgWNgACgkQM0LLzLt8MhzcMgCdHASZt+7SWGzcPYlaW+5kijMY EDgAnRjr8APT5krnDH1WNXxmKEEqgfrT =8OCG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878w677f3b@merciadriluca-station.merciadriluca
Re: Why does GNOME take so much time to tell that a screensaver-introduced password is erroneous?
On Mon, 21 Jun 2010 23:35:37 +0200 Merciadri Luca luca.mercia...@student.ulg.ac.be wrote: Hi, I use GNOME. I have noticed that if I type some erroneous password to leave the screensaver mode, GNOME takes ~3 or 4 secs. to tell me that it is erroneous. If I type the correct password, I am directly sent in my session. Why does it take so much time to tell me that a password is erroneous? I can even know if I made a typo by looking at how much time it takes! Same thing with xscreensaver. I think that a lot of software that asks for a password behaves like this, perhaps to prevent brute-forcing? I'm not sure if brute-forcing is possible on a GUI, though. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100621174721.6d022ca4.cele...@gmail.com
Re: Why does GNOME take so much time to tell that a screensaver-introduced password is erroneous?
On 06/21/2010 04:47 PM, Celejar wrote: On Mon, 21 Jun 2010 23:35:37 +0200 Merciadri Lucaluca.mercia...@student.ulg.ac.be wrote: Hi, I use GNOME. I have noticed that if I type some erroneous password to leave the screensaver mode, GNOME takes ~3 or 4 secs. to tell me that it is erroneous. If I type the correct password, I am directly sent in my session. Why does it take so much time to tell me that a password is erroneous? I can even know if I made a typo by looking at how much time it takes! Same thing with xscreensaver. I think that a lot of software that asks for a password behaves like this, perhaps to prevent brute-forcing? I'm not sure if brute-forcing is possible on a GUI, though. Since I notice the same issue when logging in from the console, could it be a problem with libpam? -- Seek truth from facts. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1fe2a5.9010...@cox.net
Re: Why does GNOME take so much time to tell that a screensaver-introduced password is erroneous?
Hi! On Mon, Jun 21, 2010 at 05:47:21PM -0400, Celejar wrote: On Mon, 21 Jun 2010 23:35:37 +0200 Merciadri Luca luca.mercia...@student.ulg.ac.be wrote: I use GNOME. I have noticed that if I type some erroneous password to leave the screensaver mode, GNOME takes ~3 or 4 secs. to tell me that it is erroneous. If I type the correct password, I am directly sent in my session. Why does it take so much time to tell me that a password is erroneous? I can even know if I made a typo by looking at how much time it takes! I believe that artificially introducing a delay when wrong credentials are presented is standard operating procedure for most things where a password must be entered. As far as I know, there are several rationales behind this: - To frustrate anybody trying to guess passwords. Being allowed to try many combinations in a short time helps make things difficult for attackers, and does not help legitimate users. - To avoid leaking information: If entering a nearly-correct password responds faster than when entering an obviously-wrong password, an attacker can use this to improve the guesses - sort of triangulating. If it always takes the same amount of time before the wrong username/password reply comes, this information is not available to a prospective attacker. I presume that some implementations add a random delay to obfuscate things further. All in all, this makes things more difficult for attackers, whilst only being a minor inconvenience for the good guys: a good trade-off. Same thing with xscreensaver. I think that a lot of software that asks for a password behaves like this, perhaps to prevent brute-forcing? I'm not sure if brute-forcing is possible on a GUI, though. I suspect this is simply a problem of aquiring the right tools for the job: - X events can be generated by software (e.g. the xmacro package). This is evident if you use VNC to control a remote machine: the screen saver is none-the-wiser to the fact that you are remote. - USB keyboards can probably be simulated by other devices. I would not be surprised to find linux tools that allow a PC to act as a USB device, rather than USB master. From here on, it is just software again. and probably lots of other ways... -- Karl E. Jorgensen IT Operations Manager -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100621221147.ge19...@hawking.jorgensen.org.uk
Re: Why does GNOME take so much time to tell that a screensaver-introduced password is erroneous?
On Mon, 21 Jun 2010 23:11:50 +0100 Karl E. Jorgensen k...@fizzback.net wrote: Hi! On Mon, Jun 21, 2010 at 05:47:21PM -0400, Celejar wrote: ... Same thing with xscreensaver. I think that a lot of software that asks for a password behaves like this, perhaps to prevent brute-forcing? I'm not sure if brute-forcing is possible on a GUI, though. I suspect this is simply a problem of aquiring the right tools for the job: - X events can be generated by software (e.g. the xmacro package). This is evident if you use VNC to control a remote machine: the screen saver is none-the-wiser to the fact that you are remote. - USB keyboards can probably be simulated by other devices. I would not be surprised to find linux tools that allow a PC to act as a USB device, rather than USB master. From here on, it is just software again. and probably lots of other ways... Good points; I should have realized this. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100621194402.bf3f1c1d.cele...@gmail.com
