On 2023-08-14 12:56 am, Lucas Nussbaum wrote:
This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).
dh clean
dh_auto_clean
make -j8 distclean
make[1]: Entering directory '/<>'
dpkg-source: info: local changes
Package: dropbear
Version: 2019.78-2
Severity: normal
The dropbear package currently has Recommends: dropbear-initramfs
so installing dropbear pulls in 30MB of other initramfs-related packages
not needed for a container. "Suggests" would seem more appropriate going by
the policy manual "The
Hi Raphael,
> When you say "upstream" here, you refer to login or dropbear?
> You are explaining that the distinction in the PATH set for root and
> non-root already exists in login... so you agree that a similar change
> ought to be done in dropbear, is that correct ?
Dropbear "upstream" will
> When dropbear is used in a very restricted environment (such as in a
> initrd), the default user shell is often also very restricted
> and doesn't take care of setting the PATH so the user ends up
> with the PATH set by dropbear. Unfortunately, dropbear always
> sets "/usr/bin:/bin" as default
The attached patch from
https://github.com/apavel/jdresolve/commit/71b9c86429c815933f42a2921dc9fbbe29c014fc
works for me and looks OK. Can it be applied?
Thanks,
Matt
jdresolve-update.diff
Description: Binary data
Try version 2012.55-1.4.
Cheers,
Matt
On Wed, Oct 23, 2013 at 03:40:54PM +0200, billw...@england.edu wrote:
Package: dropbear
Version: 2012.55-1.3
Severity: important
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the
Hi,
As Dropbear upstream I'm keen to see this fixed. Given how
many Debian Dropbear bugs are in the initramfs portion,
perhaps the initramfs setup of Dropbear should go into its
own package for people who want it?
Cheers,
Matt
On Sun, Nov 11, 2012 at 02:18:17AM +0100, Lars Wilke wrote:
This is fixed in the latest upstream release 2011.54
Matt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This is fixed in the latest Dropbear release 2011.54
Matt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The next release of Dropbear will set bindv6only on
listening sockets by default.
Matt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I think I had to add the sysctl net.ipv6.bindv6only=1 to get
Dropbear to listen on ipv6 on Debian. Dropbear just iterates
over all available addresses, I don't _think_ it's a bug in
Dropbear itself.
Matt
Dropbear developer
On Fri, Aug 05, 2011 at 09:49:41PM +1000, Chris Deigan wrote:
Package:
These files are not from upstream, they're part of the
Debian runit configuration (which is optional, off by
default).
They are not log files (well, one is a symlink to
/var/log/dropbear) or runtime status files, but rather
config files for Dropbear. I see no problem with readonly
On Sun, Sep 06, 2009 at 07:18:16PM +0300, Jari Aalto wrote:
FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION
The /etc hierarchy contains configuration files. A configuration
file is a local file used to control the operation of a program; it
Dropbear 0.52 should be using /dev/urandom, which AFAIK
won't block? Unless the behaviour of recent kernels has
changed...
If Dropbear is blocking on the random device it should log
something - could you check the auth logs?
Matt
On Tue, Sep 01, 2009 at 11:42:14AM +0200, deb...@x.ray.net
On Wed, Aug 20, 2008 at 07:43:58PM +0200, Luca Capello wrote:
Package: dropbear
Version: 0.51-1
Severity: normal
Hello,
according to [1], dbclient supports compression since version 0.47, but
I cannot find any reference of it in the manpage nor in the various
READMEs provided in the
On Wed, Mar 26, 2008 at 05:25:12PM +, Gerrit Pape wrote:
On Mon, Mar 24, 2008 at 05:13:58PM +0200, Jari Aalto wrote:
TEST SETUP:
1) run dropbear from xinetd at host A: /etc/xinetd.d/dropbear
2) try to upload anything from host B to host A (above), using openssh scp:
Hi Jari,
I don't think Recommends is appropriate for the general
case - it's meant for packages used in all but unusual
installations (from the policy manual) isn't it?
The key generation should be able to be performed using
dropbearkey (and /usr/lib/dropbear/dropbearconvert if
required), without needing
I've had a few reports of this but can't reproduce it, which
is awkward for debugging. Is there anything of note about the OS or
hardware that might help?
Dropbear is actually returning no exit status packet at all,
and the ssh client itself sets 255 (AFAICT). A successful
run is below
Is there anything in /var/log/auth ? That's where logging
should end up.
Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi.
Dropbear 0.49 (released 23 Feb 07) fixes this issue.
Cheers,
Matt Johnston
Dropbear developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi.
I can confirm that Samoied's patch works for our purpose. We
have various user accounts on a shell machine, and most
users don't care about OTP auth. To avoid confusion upon
mistyped passwords it's preferable to present non-OTP users
with another plain pam_unix password prompt, rather than
. Might be worth trying 0.48 with the sarge build
environment?
Matt Johnston
Dropbear developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libc6
Version: 2.3.5-8.1
Severity: normal
libc6 has a hardcoded list of processes (mostly servers) to restart in
its postinst script. Some important services (in this case Dropbear ssh
daemon) are not restarted, which can render a system unusable without a
reboot.
dropbear should be
On Mon, May 23, 2005 at 08:52:28AM +, Gerrit Pape wrote:
Hi Jari, on followup please respect Reply-To:.
On Sun, May 22, 2005 at 10:06:26AM +0300, Jari Aalto wrote:
| On Tue, May 17, 2005 at 09:33:43PM +0300, Jari Aalto wrote:
| It would be better if dropbear(1) manual page followed
On Mon, Mar 28, 2005 at 06:30:28PM -0500, Sam Hartman wrote:
Steve == Steve Langasek [EMAIL PROTECTED] writes:
Steve It seems to me that it would be better to fix this in the
Steve mount options for the NFS mount in question...
Hmm. Actually, will a signal even interrupt an NFS
Package: libpam-modules
Version: 0.76-22
Severity: normal
The pam_mail module attempts to perform stat() of the mail location.
If the mail location is NFS mounted and that server is unavailable,
logins as any user (root included) will hang indefinitely (hampering
attempts to umount the NFS mount
26 matches
Mail list logo
