Bug#605090:

[Jacob Appelbaum]

For those following along at home, I would suggest booting the grsec
enabled kernel once - then saving the output of `sudo lsmod` into a
file. Take every module you want (ie: all of them) and put the list
into /etc/initramfs-tools/modules - then you'll need to run
`dpkg-reconfigure linux-image-4.3.0-1-grsec-amd64` to ensure that
those modules are in the initramfs at boot time.

This should allow you to disable all module loading and thus close a
rather serious vulnerability: the ability to load kernel modules if
you are root. If the attacker has to force you to reboot, it also
means that the attacker has to leave a trace behind... First reboot
and make sure that it works and if it does, then set the sysctl
'kernel.modules_disabled=1' in /etc/sysctl.d/grsec.conf to stop all
module loading after that sysctl is set. This is also probably a fine
time to have finished your grsec tuning and so you can also probably
set `kernel.grsecurity.grsec_lock=1` as well.

The above may not work for everyone - and you may want to trim the
/etc/initramfs-tools/modules file to be less than the full output of
`lsmod` - ykmmv...

Bug#605090:

[Jacob Appelbaum]

On 12/21/15, Mickaël Salaün <m...@digikod.net> wrote:
> On 21/12/2015 00:14, Jacob Appelbaum wrote:
>> I was left with:
>>
>> [ 1802.373906] grsec: denied untrusted exec (due to not being in
>> trusted group and file in non-root-owned directory) of
>> /run/user/1000/orcexec.bCtW1V by
>> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
>> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
>> uid/euid:0/0 gid/egid:0/0
>> [ 1802.373967] grsec: denied untrusted exec (due to not being in
>> trusted group and file in non-root-owned directory) of
>> /home/error/orcexec.SzaIXb by
>> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
>> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
>> uid/euid:0/0 gid/egid:0/0
>> [ 1802.374015] grsec: denied untrusted exec (due to not being in
>> trusted group and file in world-writable directory) of
>> /tmp/orcexec.5bPuTr by /usr/bin/pulseaudio[alsa-source-ALC:3038]
>> uid/euid:1000/1000 gid/egid:1000/1000, parent
>> /lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
>>
>> I have no idea why pulse audio is trying to exec anything but audio
>> works fine regardless - so I'm just going to ignore it.
>
> grsecurity enforce a healthy execution environment not respected by liborc.
> Pulseaudio creates executable files in /tmp, writable by everyone (with the
> sticky-bit exception), which are then forbidden from being executed.
>

Oh - I'm well aware that grsecurity is doing the correct thing! I'm
rather asking, why does pulse audio do this crazy thing? :-(

> You can set $TMPDIR to a private directory (e.g. /home//tmp) and this
> should do the trick. However, the better solution is to create a private FS
> namespace for your user (e.g. using pam_namespace) to polyinstanciate a
> private /tmp for every user.

I think grsecurity will still stop it as the trusted path execution
should stop it.

Bug#605090:

[Jacob Appelbaum]

I'm also running this kernel with AppArmor and it seems to work without issue.

I followed the steps on https://wiki.debian.org/AppArmor/HowToUse
which sets "apparmor=1 security=apparmor" on the kernel command line
as documented:

sudo perl -pi -e 's,GRUB_CMDLINE_LINUX="(.*)"$,GRUB_CMDLINE_LINUX="$1
apparmor=1 security=apparmor",' /etc/default/grub
sudo update-grub
sudo reboot

It works without issue. This gives a kernel with grsecurity and
apparmor - hooray!

Bug#605090:

[Jacob Appelbaum]

To make my Debian Jessie system work with pax, I had to set pax flags
for these three binaries:

  paxctl -c -m /usr/bin/gnome-shell
  paxctl -c -m /usr/bin/gnome-session
  paxctl -c -m /usr/bin/pulseaudio

If you don't want to modify the binary, you can also set the
attributes in the file system:

  setfattr -n user.pax.flags -v m /usr/bin/gnome-shell
  setfattr -n user.pax.flags -v m /usr/bin/gnome-session
  setfattr -n user.pax.flags -v m /usr/bin/pulseaudio

You will need the `attr` package to run the above command. See
https://wiki.debian.org/grsecurity/setfattr for more information. It
may make sense to add a suggestion on the grsec kernel package for
attr.

The above allowed me to properly start GDM and to login to my system.
To use iceweasel and other utilities, I had to modify other things. I
also was able to set `kernel.grsecurity.disable_priv_io=0` after
running the setfattr commands above.

I additionally had to set the following to make the following programs
"work" with this kernel:

  setfattr -n user.pax.flags -v m /usr/bin/seahorse
  setfattr -n user.pax.flags -v m /usr/bin/iceweasel
  setfattr -n user.pax.flags -v m /usr/bin/chromium
  setfattr -n user.pax.flags -v m /usr/lib/chromium/chromium

For those who care pulse audio was also making some log entries about
"denied resource overstep by requesting 25 for RLIMIT_NICE against
limit 0 for /usr/bin/pulseaudio" - I reconfigured it with an edit to
/etc/pulseaudio/daemon.conf to add 'high-priority = no' and the kernel
stopped complaining.

I now only see two grsec denied messages on by Debian jessie system after boot:

[9.560994] grsec: denied use of ioperm() by
/usr/lib/xorg/Xorg[Xorg:891] uid/euid:0/0 gid/egid:0/0, parent
/usr/sbin/gdm3[gdm3:885] uid/euid:0/0 gid/egid:0/0
[   12.091674] grsec: denied priority change of process
(rtkit-daemon:1066) by /usr/lib/rtkit/rtkit-daemon[rtkit-daemon:1066]
uid/euid:107/107 gid/egid:114/114, parent
/lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0

After login - I see the following grsec messages:

[  448.243314] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/run/user/1000/orcexec.pIjl0t by
/usr/bin/pulseaudio[alsa-source-ALC:1617] uid/euid:1000/1000
gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
uid/euid:0/0 gid/egid:0/0
[  448.243366] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/home/error/orcexec.iEBctM by
/usr/bin/pulseaudio[alsa-source-ALC:1617] uid/euid:1000/1000
gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
uid/euid:0/0 gid/egid:0/0
[  448.243405] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of
/tmp/orcexec.VrI4V4 by /usr/bin/pulseaudio[alsa-source-ALC:1617]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
[  448.999276] grsec: denied RWX mmap of  by
/usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999349] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of /tmp/ffixSCBQp
by /usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999395] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of
/var/tmp/ffiQhZWhL by
/usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999422] grsec: denied untrusted exec (due to not being in
trusted group and file in world-writable directory) of
/dev/shm/ffi5YViJ6 by
/usr/share/system-config-printer/applet.py[applet.py:1661]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-session[x-session-manag:1464] uid/euid:1000/1000
gid/egid:1000/1000
[  448.999457] grsec: more alerts, logging disabled for 10 seconds
[  449.760884] EXT4-fs (sdb1): mounted filesystem with ordered data
mode. Opts: (null)

To eliminate most of those issues, I ran:

  setfattr -n user.pax.flags -v m /usr/bin/seahorse
  setfattr -n user.pax.flags -v m /usr/bin/gjs-console
  setfattr -n user.pax.flags -v m /usr/bin/python

I was left with:

[ 1802.373906] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/run/user/1000/orcexec.bCtW1V by
/usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
uid/euid:0/0 gid/egid:0/0
[ 1802.373967] grsec: denied untrusted exec (due to not being in
trusted group and file in non-root-owned directory) of
/home/error/orcexec.SzaIXb by

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Jacob Appelbaum]

It may make sense for us to have a package of paxrat with common
configurations for Debian users:

  https://github.com/subgraph/paxrat

This would ensure that everyone can use this kernel and have xorg work
as expected, for example.

Otherwise, I think we will see a lot of people who just run:

  paxctl -m /usr/bin/Xorg

paxctl one off runs isn't great for a full solution.

paxrat improves on this as package updates and other things can stomp
on pax related xattributes. paxrat seems very very useful in this
context - we get configuration files as well as dpkg hooks.

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Jacob Appelbaum]

On 12/19/15, Yves-Alexis Perez  wrote:
> On jeu., 2015-11-05 at 22:08 +0100, Yves-Alexis Perez wrote:
>> On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
>> > This is really a work in progress and this mail a request for comment.
>> > Especially missing is:
>>
>> So, did any of you have the chance to test it? I'm currently running the
>> 4.2.5
>> kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my
>> repository
>> and to git.d.o) and it works just fine.
>>
>> I'm really interested by any feedback you would have on this.
>>
> With a lot of help from Ben I've made quite some progress in having the
> less possible differences with src:linux package. With 4.3.3 we still have few
> things differing, some of them which I think will be integrated in the
> upcoming src:linux releases.
>

Great news - this looks fantastic!

> I'm intending to upload the current version to NEW during the week-end, so
> if any of you want to test it, now would be a good time.
>

I've installed it - I've also tuned a few things. It seems to work as
well as my previous kernel - audio works, etc.

> You can find it on the git repository
> at https://anonscm.debian.org/cgit/colla
> b-maint/linux-grsec.git and the source and binary packages on my apt
> repository
> at https://perso.corsac.net/~corsac/debian/kernel-grsec/packages/

To boot Debian Jessie (with some testing pacakes too) to X - I had to set:

kernel.grsecurity.disable_priv_io=0
kernel.pax.softmode=1
kernel.grsecirity.grsec_lock=0

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Jacob Appelbaum]

On 12/19/15, Jacob Appelbaum <ja...@appelbaum.net> wrote:
> On 12/19/15, Yves-Alexis Perez <cor...@debian.org> wrote:
>> On jeu., 2015-11-05 at 22:08 +0100, Yves-Alexis Perez wrote:
>>> On sam., 2015-10-10 at 21:55 +0200, Yves-Alexis Perez wrote:
>>> > This is really a work in progress and this mail a request for comment.
>>> > Especially missing is:
>>>
>>> So, did any of you have the chance to test it? I'm currently running the
>>> 4.2.5
>>> kernel with grsecurity-3.1-4.2.5-201511021814 (just uploaded to my
>>> repository
>>> and to git.d.o) and it works just fine.
>>>
>>> I'm really interested by any feedback you would have on this.
>>>
>> With a lot of help from Ben I've made quite some progress in having the
>> less possible differences with src:linux package. With 4.3.3 we still have
>> few
>> things differing, some of them which I think will be integrated in the
>> upcoming src:linux releases.
>>
>
> Great news - this looks fantastic!
>
>> I'm intending to upload the current version to NEW during the week-end,
>> so
>> if any of you want to test it, now would be a good time.
>>
>
> I've installed it - I've also tuned a few things. It seems to work as
> well as my previous kernel - audio works, etc.
>
>> You can find it on the git repository
>> at https://anonscm.debian.org/cgit/colla
>> b-maint/linux-grsec.git and the source and binary packages on my apt
>> repository
>> at https://perso.corsac.net/~corsac/debian/kernel-grsec/packages/
>
> To boot Debian Jessie (with some testing pacakes too) to X - I had to set:
>
> kernel.grsecurity.disable_priv_io=0
> kernel.pax.softmode=1
> kernel.grsecirity.grsec_lock=0
>

With that stuff set - I also see the following:

Dec 19 17:44:32 vula kernel: [ 4047.508272] WARNING: CPU: 5 PID: 2109
at /build/linux-grsec-4.3.3/debian/build/s
ource_grsec/include/drm/drm_crtc.h:1577
drm_helper_choose_crtc_dpms+0x8e/0x90 [drm_kms_helper]()
Dec 19 17:44:32 vula kernel: [ 4047.508272] Modules linked in:
binfmt_misc cfg80211 bridge stp llc snd_hda_codec
_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_codec nouveau snd_hda_core intel_rapl io
sf_mbi snd_hwdep ttm eeepc_wmi x86_pkg_temp_thermal asus_wmi
drm_kms_helper sparse_keymap intel_powerclamp coret
emp snd_pcm rfkill drm iTCO_wdt video iTCO_vendor_support i2c_algo_bit
snd_timer kvm_intel fb_sys_fops mxm_wmi sb_edac syscopyarea psmouse
pcspkr mei_me serio_raw edac_core kvm joydev lpc_ich sysfillrect mei
snd mfd_core evdev sysimgblt soundcore i2c_i801 shpchp 8250_fintek wmi
tpm_infineon tpm_tis processor tpm button loop fuse autofs4 ext4 crc16
mbcache jbd2 algif_skcipher af_alg uas usb_storage hid_generic
hid_cherry usbhid hid dm_crypt dm_mod sg sd_mod crct10dif_pclmul
crc32_pclmul crc32c_intel jitterentropy_rng hmac drbg ahci libahci
ansi_cprng aesni_intel aes_x86_64 xhci_pci lrw gf128mul glue_helper
ablk_helper ehci_pci libata ehci_hcd xhci_hcd cryptd e1000e ptp
scsi_mod usbcore usb_common pps_core
Dec 19 17:44:32 vula kernel: [ 4047.508303] CPU: 5 PID: 2109 Comm:
kworker/5:0 Tainted: GW   4.3.0-1-grsec-amd64 #1 Debian
4.3.3-1+grsec1
Dec 19 17:44:32 vula kernel: [ 4047.508304] Hardware name: System
manufacturer System Product Name/P9X79, BIOS 4608 12/24/2013
Dec 19 17:44:32 vula kernel: [ 4047.508305] Workqueue: events a0696b70
Dec 19 17:44:32 vula kernel: [ 4047.508305]  
729b2a82b7c3ba87  a04779a0
Dec 19 17:44:32 vula kernel: [ 4047.508307]  812f376f
 810648e7 880dfb95d000
Dec 19 17:44:32 vula kernel: [ 4047.508308]  880036954000
 0003 
Dec 19 17:44:32 vula kernel: [ 4047.508310] Call Trace:
Dec 19 17:44:32 vula kernel: [ 4047.508314]  [] ?
sysrq_drm_fb_helper_restore_op+0x20/0x2db9 [drm_kms_helper]
Dec 19 17:44:32 vula kernel: [ 4047.508315]  [] ?
dump_stack+0x40/0x61
Dec 19 17:44:32 vula kernel: [ 4047.508317]  [] ?
warn_slowpath_common+0x77/0xb0
Dec 19 17:44:32 vula kernel: [ 4047.508319]  [] ?
drm_helper_choose_crtc_dpms+0x8e/0x90 [drm_kms_helper]
Dec 19 17:44:32 vula kernel: [ 4047.508322]  [] ?
drm_helper_connector_dpms+0x60/0x100 [drm_kms_helper]
Dec 19 17:44:32 vula kernel: [ 4047.508338]  [] ?
nouveau_connector_hotplug+0x69/0xb0 [nouveau]
Dec 19 17:44:32 vula kernel: [ 4047.508346]  [] ?
nvif_notify_work+0x2c/0xc0 [nouveau]
Dec 19 17:44:32 vula kernel: [ 4047.508355]  [] ?
nvkm_notify_work+0x78/0x80 [nouveau]
Dec 19 17:44:32 vula kernel: [ 4047.508356]  [] ?
process_one_work+0x14d/0x390
Dec 19 17:44:32 vula kernel: [ 4047.508358]  [] ?
worker_thread+0x63/0x490
Dec 19 17:44:32 vula kernel: [ 4047.508359]  [] ?
rescuer_thread+0x320/0x320
Dec 19 17:44:32 vula kernel: [ 4047.508360]  [] ?

Bug#793987: xul-ext-torbirdy: Torbirdy options not visible in Icedove 31.7.0

[Jacob Appelbaum]

On 8/24/15, intrigeri intrig...@debian.org wrote:
 Hi Ben, hi Jacob,

 Ben Bailess wrote (29 Jul 2015 15:55:12 GMT) :
 I recently installed Torbirdy using the pkg xul-ext-torbirdy in order to
 have
 connection to system tor by default. When I open icedove, I do not see the

 typical green text at the bottom of the status bar stating Torbirdy
 Enabled:
 Tor... so I purged the pkg and reinstalled, with no change.

 Thanks for this bug report. It seems that Icedove 31.7 landed in
 stable and testing ~3 months ago, so I'm kinda surprised that nobody
 else reported this problem to Debian. popcon is low, but still.


I'm also surprised - I totally missed this bug though, so I'm not too surprised.

 Jake: are you aware of this problem? Is it fixed upstream in 0.1.4?

I think it is indeed fixed in 0.1.4 and it seems that Ben has confirmed it.

 Do you have time to take care of it? Or should we look into other
 options (e.g. pkg-moz-ext, as suggested a while ago, and/or the new
 pkg-privacy team)?


I don't have time in the next week or two - no.

 Also, note that torbirdy is scheduled to be removed from testing in
 a few days, due to this bug.

Oh dear - I had missed that entirely.


 I then purged the pkg again and installed from Icedove add-ons, and
 it worked as intended, [...]

 Ben: what exact version of Torbirdy did you install this way?

I think based on timing it had to be 0.1.4 if it was installed from
addons.mozilla.org.


 Let me know if I can help with anything to facilitate the package
 being updated.

 Ben: If you are knowledgeable about Debian packaging, the you'll find
 all the pointers you need there:
 https://tracker.debian.org/pkg/torbirdy

If I understand the issue, I believe we just need to upload 0.1.4 - it
is straight forward.

Bug#790947: golang-xmpp-dev: Wrong homepage in control file

[Jacob Appelbaum]

On 7/3/15, Bastian Neuburger b.neubur...@gsi.de wrote:
 Source: golang-xmpp-dev
 Severity: minor

 DUCK reported a problem with the homepage set in the source packages
 control file.

 Currently it points to https://www.github.com/agl/xmpp

That was the correct url at the time.

 However it seems that this code was moved to
 https://www.github.com/agl/xmpp-client as noted in [1], thus the
 homepage field should probably be updated to the new URL as probably
 also the debian/rules file to enable future builds.


That is new location but that is not what I have packaged.

All the best,
Jacob


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783174: www.google.com

[Jacob Appelbaum]

I'd like to use a Debian server - which one would fit?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783174: tlsdate: Time retrieved from default host (www.ptb.de) jumping all over the place?

[Jacob Appelbaum]

On 4/27/15, Rian Hunter r...@thelig.ht wrote:
 Hi,

 This totally hosed all of my systems!!


Sorry to hear that this issue has caused you problems. :(

 I think relying on the internal server_random member of the ssl data
 structure is error prone and to me it's not unexpected that a server would
 randomize the timestamp part of their random ssl seed. The erroroneous code
 is in src/tlsdate-helper.c line 1207.

That isn't a bug - code upstream in other proejcts has changed since
this was implemented. At the time of creating tlsdate, the TLS spec
specifically that it must not be randomized but rather a time stamp.


 My suggestion is that instead of changing the default server, instead
 default to using the HTTP Date header. This header is intended to contain
 the current time.

That's a nice thing to do but realistically - you need to pick a
server that you trust.


 I achieved this by changing the DAEMON_OPTS in /etc/default/tlsdated

 DAEMON_OPTS=-- /usr/bin/tlsdate -w

That is a fine way to set it, yes.


 You also have to change how DAEMON_ARGS is set in /etc/init.d/tlsdated. Add
 this line after the line that sourced /etc/default/tlsdated:

 [ -r /etc/default/$NAME ]  . /etc/default/$NAME
 DAEMON_ARGS=-f /etc/tlsdate/tlsdated.conf $DAEMON_OPTS


If you think there is a different bug, please open another bug?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783174: tlsdate: Time retrieved from default host (www.ptb.de) jumping all over the place?

[Jacob Appelbaum]

Hi Sebastian,

On 4/23/15, Sebastian Pipping sebast...@pipping.org wrote:
 Package: tlsdate
 Version: 0.0.12-2~bpo70+1
 Severity: normal

 When using debian.org for a host, time is somewhat stable:

 $ for i in {1..10}; do tlsdate --dont-set-clock --showtime -H debian.org ;
 done
 Thu Apr 23 13:06:59 CEST 2015
 Thu Apr 23 13:06:58 CEST 2015
 Thu Apr 23 13:06:58 CEST 2015
 Thu Apr 23 13:06:59 CEST 2015
 Thu Apr 23 13:07:00 CEST 2015
 Thu Apr 23 13:07:01 CEST 2015
 Thu Apr 23 13:07:03 CEST 2015
 Thu Apr 23 13:07:01 CEST 2015
 Thu Apr 23 13:07:02 CEST 2015
 Thu Apr 23 13:07:03 CEST 2015

 However, the default host www.ptb.de off pristine
 /etc/tlsdate/tlsdated.conf
 shows different behavior:

 $ for i in {1..10}; do tlsdate --dont-set-clock --showtime -H www.ptb.de ;
 done
 | sed 's|CET|CET |'
 Thu Jan 18 00:20:52 CET  1973
 Sun Apr 22 21:45:01 CEST 2018
 Thu Nov 25 03:42:48 CET  1971
 Wed Oct 23 06:20:11 CEST 1996
 Tue Jan 29 07:36:25 CET  2104
 Wed Aug  2 08:54:05 CEST 2017
 Sat Jan 13 03:44:29 CET  2046
 Fri Jan 28 04:20:04 CET  2101
 Sun Dec 27 03:11:09 CET  2105
 Fri Feb  8 05:32:52 CET  2013

 I am unsure if that's a bug in tlsdate or broken/compromised setup at
 www.ptb.de. Any ideas?


ptb.de appears to be randomizing time stamps. I'm open to a new
default host for Debian or for upstream. Thoughts? A TLS enabled
debian.org host (which one?) could do the trick if it wouldn't upset
anyone.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783193: tlsdate: Sets time wrong

[Jacob Appelbaum]

On 4/23/15, Kurt Roeckx k...@roeckx.be wrote:
 Package: tlsdate
 Version: 0.0.12-2
 Severity: grave

 Hi,

 I found this in my syslog today:
 Apr 23 16:09:23 intrepid tlsdated[3408]: [event:action_run_tlsdate]
 requested re-run of tlsdate while tlsdate is running
 Apr 23 16:09:23 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 3466176706
 Apr 23 16:09:39 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 2110302677
 Apr 23 16:09:40 intrepid tlsdated[3408]: [event:action_run_tlsdate]
 requested re-run of tlsdate while tlsdate is running
 Apr 23 16:09:40 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 198483556
 Apr 23 16:09:48 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 42183177
 Apr 23 16:09:53 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 3462611409
 Apr 23 16:09:58 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 3695382819
 Apr 23 16:10:02 intrepid tlsdated[3408]: [event:action_run_tlsdate]
 requested re-run of tlsdate while tlsdate is running
 Apr 23 16:10:02 intrepid last message repeated 4 times
 Apr 23 16:10:02 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 404492764
 Apr 23 16:10:03 intrepid tlsdated[3408]: [event:action_run_tlsdate]
 requested re-run of tlsdate while tlsdate is running
 Apr 23 16:10:03 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 2661297035
 Apr 23 16:10:04 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 2210707233
 Apr 23 16:10:04 intrepid tlsdated[3408]: [event:action_tlsdate_status]
 invalid time received from tlsdate: 3820078853
 Apr 23 16:10:05 intrepid tlsdated[3408]: [event:action_run_tlsdate]
 requested re-run of tlsdate while tlsdate is running
 Apr 23 16:10:05 intrepid tlsdated[3408]: [event:action_run_tlsdate]
 requested re-run of tlsdate while tlsdate is running
 Oct  4 11:10:36 intrepid tlsdated[3415]: synced rtc to sysclock
 Oct  4 11:10:36 intrepid named[13844]: error (no valid DS) resolving
 'ns2.mail.ru/A/IN': unknown address, family 57054
 Oct  4 11:10:36 intrepid tlsdated[3408]: [event:handle_time_setter] time set
 from the network (1570180236)
 Oct  4 11:10:36 intrepid named[13844]: validating @0x7fc5f88d97c0: . DNSKEY:
 verify failed due to bad signature (keyid=19036): RRSIG has expired
 Oct  4 11:10:36 intrepid named[13844]: validating @0x7fc5f88d97c0: . DNSKEY:
 unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a
 trusted key for '.'
 Oct  4 11:10:36 intrepid named[13844]: validating @0x7fc5f88d97c0: . DNSKEY:
 please check the 'trusted-keys' for '.' in named.conf.

 That would be Oct  4 2019.


Hi Kurt,

Could you detail which host you're using to fetch the time? I suspect
that it clearly is one that randomizes the time field (makes sense,
many do now, including the default one). Also it looks like tlsdate
failed closed many times until the server gave a mostly reasonable
answer. :)

Could you post your config? Or if not the config, could you try a
known not randomized server and confirm that my theory is correct?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772956: tlsdate: FTBFS on recent MIPS kernels

[Jacob Appelbaum]

Ok - I'll have to budget some time to look into this - I'm not sure
that I'll be able to fix this upstream in the next ~14-20days. I will
find some time in the next week to look into the details. It may be as
simple as disabling seccomp on mips for now. I'd rather not do that as
it is simply not the security direction I'd like for tlsdate...

On 12/12/14, James Cowgill james...@cowgill.org.uk wrote:
 On Fri, 2014-12-12 at 14:29 +, Jacob Appelbaum wrote:
 Thanks for the bug report!

 I think it might make sense to disable seccomp when building on that
 platform until the next upstream release. I've not had access to a
 mips64 box with seccomp - it may also be a trivial patch and I haven't
 had any time to look into this specific issue yet.

 Could you give me an idea of the timeline within this should be
 resolved to make sure we can ship a seccomp enabled tlsdate for
 mips64? Does this happen on any other mips system?

 I'm not sure if I was very clear on this. The machine is running jessie
 mipsel (ie a 32 bit userspace) but uses a 64-bit kernel - this one:
 https://packages.debian.org/sid/linux-image-3.16.0-4-loongson-3

 This was the commit in the kernel:
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=490b004fe

 Since the change was applied to config MIPS I would guess this bug
 affects all mips kernels (big / little endian, 32/64 bit, all flavours)
 since 3.15.

 James




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772956: tlsdate: FTBFS on recent MIPS kernels

[Jacob Appelbaum]

Thanks for the bug report!

I think it might make sense to disable seccomp when building on that
platform until the next upstream release. I've not had access to a
mips64 box with seccomp - it may also be a trivial patch and I haven't
had any time to look into this specific issue yet.

Could you give me an idea of the timeline within this should be
resolved to make sure we can ship a seccomp enabled tlsdate for
mips64? Does this happen on any other mips system?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772956: tlsdate: FTBFS on recent MIPS kernels

[Jacob Appelbaum]

I know that I have access to this kind of porterbox. :)

I don't know if I have the time to work on this in the next few weeks.
I hope but am not sure.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756054: default to 9050 for Debian package

[Jacob Appelbaum]

I've prepared a fix in version 0.1.3-1 - this merges the latest
release and it also includes various packaging fixes. The new version
depends on Tor and it patches TorBirdy to use 9050 rather than 9150.

The package needs review (I'm hoping Lunar^ will review, tag and
upload) but I believe everything will be solved when those three steps
occour.

Please let me know if we need to make other changes!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766579: tlsdate's apparmor rules are a bit too restrictive

[Jacob Appelbaum]

I've confirmed this issue. This bug should be fixed in the next release.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766533: tlsdate cannot be started with systemd

[Jacob Appelbaum]

Thank you for testing!

I plan to release a new tlsdate tonight - I'll tag a release and then
poke h0lger to upload it tomorrow.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766533: tlsdate cannot be started with systemd

[Jacob Appelbaum]

I'm aware of this issue with the AUR package of tlsdate - thanks for
confirming it also impacts Debian!

I'm planning a new upstream release for another minor fix - it will be
fixed in 0.0.12.

Could you confirm that it works with the following service file:
[Unit]
Description=Secure parasitic rdate replacement
After=network.target

[Service]
Type=simple
EnvironmentFile=/etc/default/tlsdated
ExecStart=/usr/sbin/tlsdated ${DAEMON_OPTS}
ExecReload=/bin/kill -HUP ${MAINPID}
ExecStop=/bin/kill -INT ${MAINPID}

If that doesn't work - I'd like to know before I upload that and some
other fixes...


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758931: acknowledge 0.0.7-1.3 NMU

[Jacob Appelbaum]

On 8/23/14, Holger Levsen hol...@layer-acht.org wrote:
 package: tlsdate

 Hi,

 please acknowledge the 0.0.7-1.3 NMU aka pick the pull requests from git
 hub.

 Maybe also a new upstream release would be nice...

Agreed. Thanks for handling the upload!

All the best,
Jacob


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751366: torbrowser-launcher: should be in contrib archive area (not main)

[Jacob Appelbaum]

On 6/12/14, Jonas Smedegaard d...@jones.dk wrote:
 Package: torbrowser-launcher
 Severity: serious
 Justification: Policy 2.2.1

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Hi,

 - From its package description, torbrowser-launcher fetches executable
 code from outside of Debian.  That is explicitly disallowed by Debian
 Policy (version 3.9.5) § 2.2.1, which states that packages in _main_...

   must not require or recommend a package outside of _main_ for
   compilation or execution

 It seems to me, therefore, that this package needs to be moved to
 contrib.


I think moving it to contrib is a fine idea. I'm working on a new
version of the package to integrate changes from upstream; I'll move
it to contrib when that package is uploaded.

Thanks for catching this!


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746606: tlsdate: incorrect path to tlsdated binary in /etc/init.d/tlsdate

[Jacob Appelbaum]

I am currently traveling in East Africa without access to my signing
keys. Furthermore, those signing keys have expired and new keys will
be generated in the near future after this trip. Pending a
regeneration of key signatures from some other Debian developers, I'll
upload a fix. If anyone wants to fix the init script before that time,
I'd be more than happy to review a fix.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741668:

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: novena-eeprom
  Version : v1.0
  Upstream Author : Sean Cross
* URL : https://github.com/xobs/novena-eeprom/
* License : BSD
  Programming Lang: C
  Description : novena eeprom editor
  Novena boards contain a device-dependent descriptive EEPROM that
defines various
  parameters such as serial number, MAC address, and featureset. This
program allows
  you to view and manipulate this EEPROM list.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741677: ITP: blockfinder -- enumerates network information for countries

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: blockfinder
  Version : v1.0
  Upstream Author : Jacob Appelbaum
* URL : https://github.com/ioerror/blockfinder/
* License : BSD-2-Clause
  Programming Lang: Python
  Description : enumerates network information for countries
  blockfinder is a simple text based console tool that returns a list of
  netblocks for a given country.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740738: ITP: golang-xmpp-dev -- pure Golang xmpp client implementation

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: golang-xmpp-dev
  Version : 0.0~20140304-1
  Upstream Author : Adam Langley a...@imperialviolet.org
* URL : http://www.github.com/agl/xmpp
* License : BSD
  Programming Lang: Golang
  Description : pure Golang xmpp client implementation
  xmpp implements the XMPP IM protocol, as specified in RFC 6120 and 6121.
  .


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740741: ITP: xmpp-client -- console XMPP client written in pure Go.

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: xmpp-client
  Version : 0.1~20140304-1
  Upstream Author : Adam Langley a...@imperialviolet.org
* URL : http://www.github.com/agl/xmpp
* License : BSD
  Programming Lang: Golang
  Description : console XMPP client written in pure Go.
  xmpp-client is a minimal console instant messaging client for the
XMPP protocol.
  It supports Off-The-Record encryption natively and may optionally use Tor or
  connect to XMPP servers hosted as Tor Hidden Services.
  .


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740364: ITP: orchid -- a tor client implementation and library written in pure java

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: liborchid-java
  Version : 1.0
  Upstream Author : Bruce Leidl br...@subgraph.com
* URL : http://www.subgraph.com/orchid.html
* License : BSD
  Programming Lang: Java
  Description : Orchid is a Tor client implementation written in pure Java.
  It was written from the Tor specification documents.
  Orchid is a Java Library that is able to function as a standalone Tor client.
  .


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#699107: Package uploaded

[Jacob Appelbaum]

I've uploaded a package - including the suggested VCS packaging
details - it is now in the new queue waiting for review by the Great
Debian Packaging Review Overlords:

   https://ftp-master.debian.org/new.html
   https://ftp-master.debian.org/new/torbirdy_0.1.2-1.html

I've also updated a related Tor Project bug about TorBirdy:

  https://trac.torproject.org/projects/tor/ticket/8030

Hooray!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739596: tlsdate: Will be broken once the SSL handshake does not include timestamps anymore?

[Jacob Appelbaum]

That is incorrect.

tlsdate will continue to function, of course. There are already
non-compliant TLS servers that do not return time or return skewed
time. We attempt to compensate for that kind of server provided data
in a few different ways. There may also be new TLS servers that
implement Nick's TLS changes.

Furthermore, the next release of tlsdate to go into Debian will have
the added code (from Nick) to fetch the data/time via HTTP, not just
the SSL/TLS handshake data.

On 2/20/14, intrig...@debian.org intrig...@debian.org wrote:
 Package: tlsdate
 Version: 0.0.5-2
 Severity: normal

 Hi,

 my understanding is that tlsdate will be broken once Nick's proposal
 is accepted, and SSL handshakes don't include timestamps anymore.

 Is this correct?
 If it is, is including tlsdate in a stable Debian release a good idea?

 Cheers,
 --
   intrigeri
   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704680: tlsdate: AppArmor profile does not support multiarch library locations = tlsdated does not start

[Jacob Appelbaum]

intrig...@debian.org:
 Package: tlsdate
 Version: 0.0.5-2
 Severity: important
 
 Hi,
 
 I'm starting tlsdate with sudo service tlsdate start on a Wheezy
 amd64 system with AppArmor enabled, and:
 
 1. tlsdated does not start, hence the normal severity.
 2. my syslog reads:
kernel: [21040.419293] type=1400 audit(1365081871.989:61):
apparmor=DENIED operation=open parent=1
profile=/usr/bin/tlsdated
name=/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 pid=6341
comm=tlsdated requested_mask=r denied_mask=r fsuid=0 ouid=0
 
 It does not look entirely scandalous that tlsdated wants to load
 libcrypto from this location, given:
 
 $ ldd /usr/bin/tlsdated | grep libcrypto
   libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
 (0x7f743b798000)
 

I've updated the AppArmor profile to include /usr/lib/x86_64-linux-gnu/
in git commit 7976210871063f98d001221a7eac6901dfd47f81. This will go
into the next tlsdate release.

 Having a look at /etc/apparmor.d/usr.bin.tlsdate, it's obvious why.
 Most profiles in there have lines such as:
 
   # Allow mapping of shared libraries
   /lib/* rm,
   /lib32/* rm,
   /lib64/* rm,
   /usr/lib/* rm,
   /lib/x86_64-linux-gnu/* rm,
 
 (with variations on this theme, some have /usr/local/lib/* too, some
 haven't, but I digress :)

I've added this to each stanza:

/usr/lib/x86_64-linux-gnu/* rm,

 
 Unfortunately, this does not support multiarch library directories.
 
 I suggest using the @{multiarch} profile variable, as most other
 profiles I have installed do, instead of trying to do it by hand.
 
 See e.g. /etc/apparmor.d/abstractions/base for nice examples of how
 one may easily support all architectures that Debian supports :)
 

I'd be interested in researching this a bit later - how does this fail?

 I suspect that /usr/bin/tlsdate-helper will need access to
 /usr/lib/@{multiarch}/* too, for the same reason.
 
 (To end with, and digressing again, it looks like the few profiles
 that are in usr.bin.tlsdate could benefit from some factorization into
 abstractions/, possibly even using existing abstractions if they're
 not to wide for your taste. Shall I file a wishlist bug about it?)
 

Ideally, I'd prefer a patch. :)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718571: Add systemd service file for tlsdate

[Jacob Appelbaum]

intrigeri:
 Hi,
 
 Moritz Muehlenhoff wrote (02 Aug 2013 12:26:16 GMT) :
 attached is a patch which adds a systemd service file for tlsdate.
 
 FWIW: applied, rebuilt package = seems to work fine for me.

I've added a basic service file to the root of the tlsdate git repo.
I'll also add it to the next debian package release in version 0.0.7
which I plan to tag in the next few days.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718572: tlsdate: Please fill Vcs-Git and Vcs-Browser control fields

[Jacob Appelbaum]

intrig...@debian.org:
 Package: tlsdate
 Version: 0.0.5-2
 Severity: wishlist
 
 It seems that Debian packaging work is published on GitHub:
 
   https://github.com/ioerror/tlsdate.git
 
 Could you please document this using the appropriate Vcs-* control
 fields, so that standard tools such as e.g. debcheckout work
 out-of-the-box?
 
 Thanks in advance :)
 

I've added them in the following commit:

  [debian-master bf361fc] Add Vcs-Git and Vcs-Browser

I used https:// rather than git:// as I think it is not safe to use any
transport other than https or ssh. I think this should be fine.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727986: fixed

[Jacob Appelbaum]

I've addressed this in the following git commit:

[debian-master 8dde3d4] call dh --with autotools_dev; closes Debian #727986


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705177: ITP: torbrowser-launcher -- A program to help you download, keep updated, and run the Tor Browser Bundle

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: torbrowser-launcher
  Version : 0.0.1
  Upstream Author : Micah Lee micahf...@riseup.net
* URL : https://github.com/micahflee/torbrowser-launcher
* License : BSD
  Programming Lang: Python
  Description : installs, updates and runs the Tor Browser Bundle

 A program to help you download, keep up to date, and run the Tor
 Browser Bundle.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#699107: ITP: TorBirdy -- configures Mozilla birds for use with Tor

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: torbirdy
  Version : 0.0.13
  Upstream Author : Jacob Appelbaum ja...@appelbaum.net
* URL : https://www.github.com/ioerror/torbirdy
* License : BSD
  Programming Lang: javascript
  Description : configures Mozilla birds for use with Tor

 The TorBirdy extension configures Thunderbird (or IceDove, etc) to make
 connections over the Tor anonymity network.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#681000: ITP: tlsdate -- secure parasitic rdate replacement

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum ja...@appelbaum.net

* Package name: tlsdate
  Version : 0.0.1
  Upstream Author : Jacob Appelbaum ja...@appelbaum.net
* URL : https://www.github.com/ioerror/tlsdate
* License : BSD
  Programming Lang: C
  Description : secure parasitic rdate replacement

tlsdate sets the local clock by securely connecting with TLS to remote
servers and extracting the remote time out of the secure handshake.
Unlike ntpdate, tlsdate uses TCP and verifies all data with
cryptographic signatures.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#556585: (no subject)

[Jacob Appelbaum]

Additionally, I should note that if I attempt to rmmod the module and
modprobe it, I have the following errors logged by my kernel:

[55412.053721] iwlagn :03:00.0: PCI INT A disabled
[55427.285783] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
1.3.27ks
[55427.285785] iwlagn: Copyright(c) 2003-2009 Intel Corporation
[55427.285845] iwlagn :03:00.0: Refused to change power state,
currently in D3
[55427.285856] iwlagn :03:00.0: PCI INT A - GSI 17 (level, low) -
IRQ 17
[55427.285903] iwlagn :03:00.0: Detected Intel Wireless WiFi Link
4965AGN REV=0x
[55427.289009] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[55427.316836] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[55427.340430] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[55427.344534] iwlagn :03:00.0: Unknown hardware type
[55427.344536] iwlagn :03:00.0: Unable to init EEPROM
[55427.344561] iwlagn :03:00.0: PCI INT A disabled
[55427.344583] iwlagn: probe of :03:00.0 failed with error -2



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#556585: X61 problem on Lenny with Backports kernel

[Jacob Appelbaum]

I'm having the same problem with my laptop X61 Lenovo laptop running Lenny:

[54510.421880] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.433558] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.443506] iwlagn :03:00.0: BSM uCode verification failed at
addr 0x3800+0 (of 788), is 0x, s/b 0xf802020
[54510.443508] iwlagn :03:00.0: Unable to set up bootstrap uCode: -5
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.447708] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.738850] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.758798] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.780043] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.797691] iwlagn :03:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL
= 0x
[54510.813181] iwlagn :03:00.0: Unable to initialize device after 5
attempts.

Long ago, I had to install a kernel from backports just to get the
device working at all. This bug has always existed in some form or
another on this laptop. However my use of wireless had been infrequent
until recently and the bug rarely popped up. Now I'm using wireless
daily and this bug is rather annoying.

I have the following for firmware:

apt-cache show firmware-iwlwifi | grep Version\|4965
Version: 0.17~bpo50+1
Description: Binary firmware for Intel Wireless 3945, 4965 and
5000-series cards
 This package contains the binary firmware for Intel Wireless 3945, 4965,
  * Intel Wireless 4965 firmware, version 228.57.1.21
  * Intel Wireless 4965 firmware, version 228.57.2.23
Version: 0.14+lenny2
Description: Binary firmware for Intel Wireless 3945 and 4965
 This package contains the binary firmware for Intel Wireless 3945 and 4965
  * Intel Wireless 4965 firmware, version 228.57.1.21
  * Intel Wireless 4965 firmware, version 228.57.2.21

% dpkg -l|grep firmware-iwlwifi
ii  firmware-iwlwifi   0.17~bpo50+1
   Binary firmware for Intel Wireless 3945, 496

% dpkg -l|grep 2.6.32|grep image
ii  linux-image-2.6.32-bpo.2-686-bigmem2.6.32-8~bpo50+1
   Linux 2.6.32 for PCs with 4GB+ RAM

This is my `uname -a` output:
Linux parcore 2.6.32-bpo.2-686-bigmem #1 SMP Tue Feb 16 08:53:00 UTC
2010 i686 GNU/Linux

The only way I can resume using my wireless card is with a full shutdown
and a fresh start. The wireless will work after a fresh boot. It will
have the above error within one day of solid wireless network use.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#556585: (no subject)

[Jacob Appelbaum]

lspci reports the following devices (both before and after module
loading or driver breakage):

00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network
Connection (rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or
AGN [Kedron] Network Connection (rev ff)

The Gigabit network card works fine and the wireless card is always on
the fritz.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#541279: (no subject)

[Jacob Appelbaum]

Thanks for the catch! I've put the proper descriptions into the package,
uploaded the changes to git and I'm waiting on my sponsor to upload a
new package. Once that's done, I'll close this bug...



signature.asc
Description: OpenPGP digital signature

Bug#495416: ITP: AESKeyFinder -- A tool for finding and reconstructing AES keys.

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Debian Forensics [EMAIL PROTECTED]

* Package name: AESKeyFinder
  Version : 1.0.0
* URL : http://citp.princeton.edu/memory/code/
* License : BSD
  Programming Lang: C
  Description : A tool for finding and repairing AES keys.

This program illustrates automatic techniques for locating 128-bit and
256-bit AES keys in a captured memory image.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495418: ITP: RSAKeyFinder -- A tool for locating RSA private and public keys.

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Debian Forensics [EMAIL PROTECTED]

* Package name: RSAKeyFinder
  Version : 1.0.0
* URL : http://citp.princeton.edu/memory/code/
* License : BSD
  Programming Lang: C++
  Description : A tool for locating RSA private and public keys.

This program illustrates automatic techniques for locating RSA
private and public keys.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495419: ITP: AESFix -- A tool for correcting bit errors in an AES key schedule.

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Debian Forensics [EMAIL PROTECTED]

* Package name: AESFix
  Version : 1.0.1
* URL : http://citp.princeton.edu/memory/code/
* License : BSD
  Programming Lang: C++
  Description : A tool for correcting bit errors in an AES key schedule.

This program illustrates a technique for correcting bit errors in an AES
key schedule. It should be used with the output of the AESKeyFinder
program.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495422: ITP: biosmemimage -- Tools for capturing memory dumps on x86 and x86-64 systems

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum [EMAIL PROTECTED]

* Package name: biosmemimage
  Version : 1.0.0
* URL : http://citp.princeton.edu/memory/code/
* License : BSD
  Programming Lang: C
  Description : Tools for capturing memory dumps on x86 and x86-64 systems

This package contains proof of concept utilities for capturing
memory dumps from Intel x86-based and AMD/Intel x86-64 based PC
systems. PXE and USB memory scraper payloads are included.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495422: ITP: biosmemimage -- Tools for capturing memory dumps on x86 and x86-64 systems

[Jacob Appelbaum]

owner 495422 Debian Forensics [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum [EMAIL PROTECTED]


* Package name: ozymandns
  Version : 0.0.1
  Upstream Author : Dan Kaminsky [EMAIL PROTECTED]
* URL : http://www.doxpara.com/ozymandns_src_0.1.tgz
* License : (Currently consulting with upstream for explicit
* license)
  Programming Lang: (C, Perl)
  Description : An experimental DNS server and miscellaneous DNS tools

OzymanDNS is a suite of tools for experimenting with DNS. It includes a
number of tools:

aska.pl - DNS File/Stream Sender
geta.pl - DNS File/Stream Receiver
nomde.pl - Experimental DNS Server
droute.pl - Reliable DNS Transport for standard input/output
glance.c - Represents IP addresses as dates

More information about all of these tools can be found in Dan's Black
Ops DNS 2004 CCC Congress slides:
http://www.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#459492: libgmp3-dev is missing any sort of useful manpage

[Jacob Appelbaum]

Package: libgmp3-dev
Version: 2:4.2.1+dfsg-4
Severity: normal

It would be quite useful if this package or its corresponding
'libgmp3-doc' package included even a single simple man page.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages libgmp3-dev depends on:
ii  libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic
library
ii  libgmpxx4 2:4.2.1+dfsg-4 Multiprecision arithmetic
library

Versions of packages libgmp3-dev recommends:
ii  libstdc++6-4.1-dev [libstdc++ 4.1.1-21   The GNU Standard C++
Library v3 (d

-- no debconf information




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319081: mono: Seriously out of date build full of problems unusable

[jacob appelbaum]

Package: mono
Version: 1.1.6-4
Severity: normal


This version of mono has fundamental garbage collection bugs that have
since been fixed. I highly recommend upgrading to at least mono 1.1.7,
which is what wikipedia has deployed. 1.1.8.2 would be even better, of
course.

Please upgrade this ASAP as mono is useless to many serious
developers. Thanks for your time!


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.5y
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages mono depends on:
ii  mono-common   1.1.6-4common files for Mono
ii  mono-jit  1.1.6-4fast CLI (.NET) JIT compiler for M

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#274603: dcraw: Support for Canon 20d is currently broken

[jacob appelbaum]

Package: dcraw
Version: 5.88-1
Followup-For: Bug #274603


The current version of dcraw in debian testing segfaults on a raw canon
20d .cr2 file:

 dcraw -v img_8727.cr2
 Loading Canon EOS 20D image from img_8727.cr2...
 Scaling with black=0, pre_mul[] = 1.00 1.00 1.00
 VNG interpolation...
 Segmentation fault

However, the new upstream version located at
http://www.cybercom.net/~dcoffin/dcraw/dcraw.c does not have this
problem:

 dcraw -v img_8727.cr2
 Loading Canon EOS 20D image from img_8727.cr2...
 Scaling with black=511, pre_mul[] = 1.95 1.00 1.36
 VNG interpolation...
 Converting to RGB colorspace...
 Writing data to img_8727.ppm...


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages dcraw depends on:
ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libjpeg62 [libjpeg6b]   6b-9 The Independent JPEG Group's JPEG 

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]