Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Anthony Towns]

On Sun, Dec 07, 2003 at 09:53:11PM +0100, Marc Haber wrote:
> >So, why can't this be done without an exim4-config package in Debian, with
> >something like the following arrangement:
> > exim4-daemon
> > provides/conflicts: mail-transport-agent
> > postinst:
> > checks /etc/exim4
> > if it doesn't exist, creates it, using debconf
> > exim4-config-ilkserver:
> > postinst:
> > rm -rf /etc/exim4
> > create /etc/exim4 according to desired config
> That looks like a bad hack.

It's a bad hack if it's difficult to maintain (doesn't seem to be),
or doesn't solve all the problems (may be). What you've currently
got is also a bad hack -- it gets exim stuff installed where it's not
wanted. The suggestion of listing every MTA specifically, rather than
usuing the virtual package we already have is also a pretty horrible hack.

> And it precludes the use of dpkg conffile handling for the config
> snippets in /etc/exim4/conf.d

Better to drop support for that than install exim4-base on non exim systems.

> And it doesn't solve the problem at hand, with exim4-base being
> installed on non-exim systems by dselect.

Have exim4-base and exim4-daemon depend on exact versions of each other,
and have exim4-base not have a postinst of its own.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004


pgpxCObj8dmjg.pgp
Description: PGP signature

Bug#223311: ITP: debsigs-ng -- create and verify signatures on .deb-files

[Andreas Barth]

Package: wnpp
Version: N/A; reported 2003-12-08
Severity: wishlist

* Package name: debsigs-ng
  Version : 0.1
  Upstream Author : Andreas Barth <[EMAIL PROTECTED]>
* URL : http://debsigs.turmzimmer.net/
* License : GPL
  Description : create and verify signatures on .deb-files

debsigs-ng is a low-level tool for creation and verification of
signature on the Debian archive files (deb).

The created signed files are strict compatible with dpkg and the
apt-utils. These tools could also verify older signatures done by
debsigs.

upload queue at erlangen

[Paul Slootman]

The developer's reference lists erlangen as one of the upload queues.
However, I used it last week (as I assumed that I wouldn't be able to
upload the way I usually did, i.e. directly to ftp-master via ssh).

However, I was wondering how long it would take (I haven't really seen
any announcement that archive updates are active again). I then tried
uploading to ftp-master-anon (which I saw mentioned somewhere), and I
got confirmation that my package had been processed very quickly!

Thus it seems that erlangen's upload queue is broken, even though it
silently accepts packages. In fact, going to
ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue/ it seems that
it's been broken since beginning of October.  Perhaps it should be
disabled, and removed from the developer's reference? Or is something
else the matter?


Paul Slootman

偷窥无罪之无线摄像头!

[小洋]

本公司专业经营各种无线摄像器材，满足各类人士的需求。本产品小巧灵活，
可以用于对婴儿的监控，和防盗，在电脑上加一块视频转接卡就可以录象了，
把你想要的录下来。（你要做别的事情我就不管了）本产品使用很方便
不需要布线，用节电池就能工作了，心动不如行动 赶快跟我们联系。QQ79651785 
[EMAIL PROTECTED]

公司网址：http://www.happyshops.net/camera 

  最大优点：1，发射器的尺寸是现阶段最小的（20*20*20 MM）有很好的隐蔽性。

   2，彩色视频和无线音频同步。（既有图像又有声音）

   3，发射器可接干电池，解决了特殊场合没有交流电的问题。


无线接收设备可直接连接电视机或者其他带AV输入的屏幕。
整套系统，安装方便，是您家庭安全的必备设备。接上录象机即可实现实时录象。
它用途广泛：用于保安，视频会议，可视门铃，可视电话，各类玩具，婴儿看护及汽车后视，
超市等众多范围！其中两个接口：一个接电视机的视频接口，一个接稳压电源。 
注意：如果想在电脑上使用，您必须有视频捕捉卡（便宜的大概200多元可以买到），接上后您就可以把

彩色CMOS芯片
最低照度:1.5LUX 
CRT 分辨率:380TV LINES 
信号制式:CCIR(PAL-NTSC)标准视频信号 
镜头焦距:=60mm 
视场角:69deg 
电源:DC6-8V/MAX 120mA 

配套的无线收发设备规格
接收器尺寸：115X60X20 MM
输出频率：900-1200MHZ
发射电平：50MW
发射距离：100米（无障碍）
配套： 
9V稳压电源1个12V稳压电源1个，电池接口线（发射头和摄像头可采用9V方块电池或蓄电池），
视频线一条

Re: Backport of the integer overflow in the brk system call

[Steinar H. Gunderson]

On Sun, Dec 07, 2003 at 09:16:58PM -0500, Patrick Ouellette wrote:
> Instead of a smartcard/token/whatever physical device, this incident
> could possibly have been thwarted by requiring developers to pre-register
> their machine with the project (using ssh host key for example).  The
> attacker would have the user's account information, but project machines
> would have refused access since the host id did not match the user's
> registered hosts.  Then the project machine could have alerted both the
> project's admin team and the owner of the compromised account.

Given that the easiest way to get a developer's password is to compromise a
machine that person logs into Debian systems from, I doubt this well help
that much. :-) The only exception I can see would be if the user uses the
same password for his/her Debian account and some other system, and the
attacker is smart enough (read: wants to go specifically after Debian) to
test that password on d.o as well.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

RE: Backport of the integer overflow in the brk system call

[Julian Mehnle]

Russell Coker wrote:
> On Mon, 8 Dec 2003 13:16, Patrick Ouellette <[EMAIL PROTECTED]> wrote:
> > Instead of a smartcard/token/whatever physical device, this incident
> > could possibly have been thwarted by requiring developers to
> > pre-register their machine with the project (using ssh host key for
> > example).  The attacker would have the user's account information,
> > but project machines would have refused access since the host id did
> > not match the user's registered hosts.  Then the project machine
> > could have alerted both the project's admin team and the owner of the
> > compromised account. 
> 
> One problem with this is developer's machines that are on dial-up
> Internet connections.  In the case of such machines you can verify the
> host key but not the IP address.

You cannot verify the IP address *exactly*, but you can verify whether the IP 
address lies within a range.  Dial-up users could at least register a certain 
address range, so as to vastly mitigate the attack risk.  Apart from that, as 
soon as the use of IPv6 broadens, dynamically assigned IP addresses will 
diminish.

> But this still leaves the issue of how to deal with dial-up machines. 
> Even if we restrict connections to a single ISP as often dial-up
> machines are not used with multiple machines, this still isn't
> necessarily much good, some dial-up ISPs have >50,000 IP addresses.

Still, IP address (even if it's a range, not a single address) verification 
vastly mitigates the attack risk.

> Finally, if the attacker can compromise the machine and the machine is
> online (EG permanently connected machines) there's no good options.

What's more secure, "no good options", or "no good options" plus IP address 
verification, even if range-based?  Some attack vectors one will never be able 
to protect against, but it still makes sense to protect against other vectors, 
doesn't it?

Re: Backport of the integer overflow in the brk system call

[Russell Coker]

On Mon, 8 Dec 2003 23:14, "Julian Mehnle" <[EMAIL PROTECTED]> wrote:
> > One problem with this is developer's machines that are on dial-up
> > Internet connections. ÂIn the case of such machines you can verify the
> > host key but not the IP address.
>
> You cannot verify the IP address *exactly*, but you can verify whether the
> IP address lies within a range. ÂDial-up users could at least register a
> certain address range, so as to vastly mitigate the attack risk. ÂApart
> from that, as soon as the use of IPv6 broadens, dynamically assigned IP
> addresses will diminish.

That will work in some situations, but not in all.

If a DD is visiting the Netherlands they may use a zonnet.nl dial-in (Zon is 
one of the biggest Dutch ISPs and a likely choice).  Zon had over 10,000 
phone lines in Amsterdam last time I checked (not sure if it has increased or 
decreased since then).  Amsterdam also has many skillful hackers (most 
ethical, but I'm sure there are some "black hats" too).  So in this situation 
(which is not very hypothetical given the number of DD's who visited me when 
I lived in Amsterdam) the DD would get random IP addresses from the same pool 
as the attacker.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

RE: Backport of the integer overflow in the brk system call

[Julian Mehnle]

Russell Coker wrote:
> On Mon, 8 Dec 2003 23:14, "Julian Mehnle" <[EMAIL PROTECTED]> wrote:
> > You cannot verify the IP address *exactly*, but you can verify
> > whether the IP address lies within a range.  Dial-up users could at
> > least register a certain address range, so as to vastly mitigate the
> > attack risk.  Apart from that, as soon as the use of IPv6 broadens,
> > dynamically assigned IP addresses will diminish.
> 
> That will work in some situations, but not in all.

True.  But even though it might not prevent *all* attacks, it will prevent 
*many*, without incurring additional costs or adding considerable complexity to 
the Debian Developer apparatus, will it not?

免费发布供求信息

[商务之窗]

您好，这是一份善意的商业邮件，如本信息对您无帮助，请随手删除，并深表歉意。
---
免费发布供求信息的好去处http://www.bizwds.com  网络实名：商务之窗

为你在深圳找寻客户、合作伙伴、供应商，做24小时的网上生意！

请登录我们网站http://www.bizwds.com  网络实名：商务之窗
---
[EMAIL PROTECTED]

Bug#223333: ITP: mecab-jumandic -- Juman dictionaries compiled for Mecab

[TSUCHIYA Masatoshi]

Package: wnpp
Severity: wishlist

* Package name: mecab-jumandic
  Version : 4.0
  Upstream Author : Sadao Kurohashi <[EMAIL PROTECTED]>
* URL or Web page : http://www.kc.t.u-tokyo.ac.jp/nl-resource/juman.html
* License : BSD
  Description : Juman dictionaries compiled for Mecab

-- 
TSUCHIYA Masatoshi

Re: Bad version number based on date advice in policy?

[Chad Walstrom]

On Mon, Dec 08, 2003 at 04:20:07PM +, Colin Watson wrote:
> That always struck me as a rather poor idea. What if we have two
> versions of a package, 1:1.0 and 2:1.0? Both will be foo_1.0_$ARCH.deb
> at the moment.

IIRC, the actual filename in the archive is

foo_1.0-${EPOCH}%3a${DEBVER}_${ARCH}.deb.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpup9YCHZ7kU.pgp
Description: PGP signature

Need help: Idle X-user?

[Dennis Stampfer]

Hi -devel,

the program timeoutd was originally written when using X was not a matter
of course:

timeoutd loggs user out when they reached timeout-restrictions like max.
login-time, max. idle-time, etc.

Some users asked for X-Support. Well, X works well with "No login
allowed at all" and "Login restricted to max. X minutes", but it does
not work with "Logout, when user U was idle Yminutes.
Support for X and "idle-logout" is not included within timeoutd. My
question is:

Is there any way to querry how long a X-user is idle? If not, do you
think it's okay to write something like "IDLE-Logout does not work
with X" into Readme.Debian and into the config-file(,manpage, ...)?

I found no way to check if a user is idle without using extra libraries,
and if I use extra libaries, new depencies are needed wich users don't
need if they have no X on their box. (these extra-depencies may depend
on X, so they need X, etc...)

thank you,
Dennis

Re: Need help: Idle X-user?

[Goswin von Brederlow]

Dennis Stampfer <[EMAIL PROTECTED]> writes:

> Hi -devel,
> 
> the program timeoutd was originally written when using X was not a matter
> of course:
> 
> timeoutd loggs user out when they reached timeout-restrictions like max.
> login-time, max. idle-time, etc.
> 
> Some users asked for X-Support. Well, X works well with "No login
> allowed at all" and "Login restricted to max. X minutes", but it does
> not work with "Logout, when user U was idle Yminutes.
> Support for X and "idle-logout" is not included within timeoutd. My
> question is:
> 
> Is there any way to querry how long a X-user is idle? If not, do you
> think it's okay to write something like "IDLE-Logout does not work
> with X" into Readme.Debian and into the config-file(,manpage, ...)?
> 
> I found no way to check if a user is idle without using extra libraries,
> and if I use extra libaries, new depencies are needed wich users don't
> need if they have no X on their box. (these extra-depencies may depend
> on X, so they need X, etc...)
> 
> thank you,
> Dennis

X screensavers usually have a logout option and there is a way to ask
X for the idle time, again screensaver use it. You should look at some
of them.

MfG
Goswin

Re: Building Debian Completely From Source

[Matt Zimmerman]

On Sun, Dec 07, 2003 at 04:10:36PM +, Scott James Remnant wrote:

> make?  You'll need make installed to make make.  There are a huge number
> of legitimate circular build dependencies, outlawing them won't help.

There are quite a few, but make is a bad example, as it has included a
shell script to build itself for just this purpose.

-- 
 - mdz

Orphaning Firebird RDBMS

[Grzegorz B. Prokopski]

Hi!

I haven't (seriously) used Firebird since a year and there's no chance
I'll be using anytime soon. It's low maintenance software though as
upstream is focused on firebird 1.5/2.0

Therefore I am going to orhpan:
* firebird
* php4-interbase (depending on firebird)

Drop me note if you want to take them over. Else - I'll orphan them
formally soon.

Cheers,

Grzegorz B. Prokopski

Description: FireBird - RDBMS based on InterBase 6.0 code

 The "classic" flavour uses new process to handle every connection.
 This results in somewhat slower operation (but it is said it is faster
 on local connections than "super"), but also can operate on many
 processors on SMP machines. This is the "traditional" flavour.

 The "super" flavour uses separate thread to handle every connection.
 It is has it's adventages (for ex. is usually faster), but also some
 disadventages (is unable to use more than one CPU on SMP systems,
 under some circumstances clients can crash all server).

 Firebird is a relational database offering many ANSI SQL-92 features
 that runs on Linux, Windows, and a variety of Unix platforms. Firebird
 offers excellent concurrency, high performance, and powerful language
 support for stored procedures and triggers. It has been used in
 production systems, under a variety of names since 1981.

 Firebird is a commercially independent project of C and C++
 programmers, technical advisors and supporters developing and enhancing
 a multi-platform relational database management system based on the
 source code released by Inprise Corp (now known as Borland Software
 Corp) under the InterBase Public License v.1.0 on 25 July, 2000.

-- 
Grzegorz B. Prokopski <[EMAIL PROTECTED]>
Debian GNU/Linux  http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org

Re: debsums for maintainer scripts

[Matt Zimmerman]

On Sun, Dec 07, 2003 at 10:42:10PM +0100, Goswin von Brederlow wrote:

> Having or not having is of the order of several 100MB. The shear
> number of debs makes the impact.

Fortunately, the actual effect is much smaller since nearly all packages
have md5sums already.

-- 
 - mdz

Re: Accounts on debian.org machines

[David B Harris]

On Mon, 08 Dec 2003 03:18:53 +
Matthew Garrett <[EMAIL PROTECTED]> wrote:
> Steve Langasek wrote:
> >But an ssh key on removable media is not vulnerable to keysniffing
> >alone, where a password is.
> 
> If such behaviour becomes common, the keysniffers will simply copy
> anything that looks like an SSH key that exists on an item of removable
> media. There's no inherent increase in security from using a key on a
> USB device other than the fact that attackers aren't thinking about that
> yet.

The old "security through obscurity" idea, eh? Well, if you *rely* on
obscurity for your security (ie: if an attacker has free reign if they
know the secret you're trying to keep [in this case, that the SSH key is
on USB media]), then sure, there's a problem. It's not a problem,
however, if it's only *part* of a security regimen.

For instance, I'll ask a simple question: does the hacker who installed
the hardware keylogger on my machine know that my SSH key is somewhere
unusual? Do they even know about SSH keys? If either of those answers is
"no", I have effectively averted a compromise, whereas even if they
*didn't* know, but I didn't use an SSH key, they'd have effective
control of my machine.

Some food for thought. Obscurity != security, but I've yet to see any
effective security regimen which did *not* include some obscurity
factors. I've also yet to see anybody post their IP address, userid, and
password for their publicly-accessible servers to a public mailing list
:)

Assurance measures: ALC (The hidden treasure of Debian)

[Magosányi Árpád]

Hi!

We will see here the assurance measures related to life cycle support.
This is an area where Debian shines out even from the other open
source projects.

ALC_DVS.2 Sufficiency of security measures (EAL6, EAL7)

ALC_DVS.2.1D The developer shall produce development security
documentation.
(Policy manual, developer's reference, and the various
policies related to project resources.)
ALC_DVS.2.1C The development security documentation shall describe
all the physical, procedural, personnel, and other security
measures that are necessary to protect the confidentiality and
integrity of the TOE design and implementation in its
development environment.
(Well, the word "confidentality" is not applicable in our
case. Otherwise there are numerous measures.)
ALC_DVS.2.2C The development security documentation shall provide
evidence that these security measures are followed during the
development and maintenance of the TOE.
(As most of the measures are enforced by technical means,
and the rest is mediated by the BTS or e-mail (mostly
mailing lists), the evidence is plenty.)
ALC_DVS.2.3C The evidence shall justify that the security measures
provide the necessary level of protection to maintain the
confidentiality and integrity of the TOE.
(After the recent breakin, one could conclude that they
aren't. But the code base isn't touched, and the necessary
lessons are being drawn.)

ALC_FLR.3 Systematic flaw remediation ("above EAL7": no flaw remediation
is mandated by any EALs)
ALC_FLR.3.1D The developer shall document the flaw remediation
procedures provide flaw remediation procedures addressed to TOE
developers.
(http://www.debian.org/security/)
ALC_FLR.3.2D The developer shall establish a procedure for accepting
and acting upon all reports of security flaws and requests for
corrections to those flaws.
(see above)
ILC_FLR.3.3D The developer shall provide flaw remediation guidance
addressed to TOE users.
(see above)
ALC_FLR.3.1C The flaw remediation procedures documentation shall
describe the procedures used to track all reported security
flaws in each release of the TOE.
(http://www.debian.org/security/faq#policy
http://www.debian.org/security/faq#testing
http://www.debian.org/security/faq#contrib)
  ALC_FLR.3.2C   The flaw remediation procedures shall require that a
description of the nature and effect of each security flaw be
provided, as well as the status of finding a correction to that
flaw.
(The advisories do that)
ALC_FLR.3.3C   The flaw remediation procedures shall require that
corrective actions be identified for each of the security
flaws.
(The advisories do that)
ALC_FLR.3.4C   The flaw remediation procedures documentation shall
describe the methods used to provide flaw information,
corrections and guidance on corrective actions to TOE users.
(Links to advisories, security announce mailing list,
and rdf newsfeeds on www.debian.org/security do that.)
ALC_FLR.3.5C   The flaw remediation procedures documentation shall
describe a means by which the developer receives from TOE users
reports and enquiries of suspected security flaws in the TOE.
( http://www.debian.org/security/faq#contact)
ALC_FLR.3.6C   The procedures for processing reported security flaws
shall ensure that any reported flaws are corrected and the
correction issued to TOE users.
(http://www.debian.org/security/faq#lifespan
It is done for all released Debian version. I judge
that this counts as fulfilling the requirement.)
ALC_FLR.3.7C   The procedures for processing reported security flaws
shall provide safeguards that any corrections to these security
flaws do not introduce any new flaws.
(http://www.debian.org/security/faq#oldversion)
ALC_FLR.3.8C   The flaw remediation guidance shall describe a means by
which TOE users report to the developer any suspected security
flaws in the TOE.
( http://www.debian.org/security/faq#contact)
ALC_FLR.3.9C   The flaw remediation procedures shall include a procedure
requiring timely responses for the automatic distribution of
security flaw reports and the associated corrections to
registered users who might be affected by the security flaw.
( the advisory mailing list registration counts as a
registration, and both the web page and the advisories
contain the distribution point for the corrections)
ALC_FLR.3.10C  The flaw remediation guidance shall describe a means by
which TOE users may register with the developer, to be eligible
to receive security reports and corrections.
(Advisory

Re: debsums for maintainer scripts

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Sun, Dec 07, 2003 at 10:42:10PM +0100, Goswin von Brederlow wrote:
> 
> > Having or not having is of the order of several 100MB. The shear
> > number of debs makes the impact.
> 
> Fortunately, the actual effect is much smaller since nearly all packages
> have md5sums already.

Having or not having. Removing them all will free the precious space
again.

My precious. MINE.

MfG
Goswin

Re: Need help: Idle X-user?

[Steve Kemp]

On Mon, Dec 08, 2003 at 07:09:59PM +0100, Dennis Stampfer wrote:

> Is there any way to querry how long a X-user is idle? If not, do you
> think it's okay to write something like "IDLE-Logout does not work
> with X" into Readme.Debian and into the config-file(,manpage, ...)?

  I'm not sure to be honest, but you could look at the code for 
 xscreensavers etc.

  As for the libraries and a dependency upon Xlibs you can get round
 this by having the package provide two binaries 'timoutd' and
 'timeoutd-x11' or something similar.

  That way users would install the one they want..

Steve
--
# Debian Security Audit Project
http://www.steve.org.uk/Debian/

Re: Bad version number based on date advice in policy?

[Rene Engelhard]

Chad Walstrom wrote:
> On Mon, Dec 08, 2003 at 04:20:07PM +, Colin Watson wrote:
> > That always struck me as a rather poor idea. What if we have two
> > versions of a package, 1:1.0 and 2:1.0? Both will be foo_1.0_$ARCH.deb
> > at the moment.
> 
> IIRC, the actual filename in the archive is
> 
>   foo_1.0-${EPOCH}%3a${DEBVER}_${ARCH}.deb.

No, they aren't.

That IIRC is something apt does with the debs, but the epoch
is _not_ in the filename of the debs in the archive..

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73
  


signature.asc
Description: Digital signature

Re: problem with bugs.debian.org

[Colin Watson]

On Tue, Dec 02, 2003 at 01:05:50AM +1000, Anthony Towns wrote:
> On Mon, Dec 01, 2003 at 01:35:38PM +0100, Stefano Zacchiroli wrote:
> > The same happened to me with a bug reported against pbbuttonsd (don't
> > have the number at hand right now). As a personal opinion I think the
> > crontabs of the BTS are on some machine still not restored after the
> > attack.
> 
> It should happen with all recently filed bugs; basically the indices
> aren't being updated properly. That's a bit odd, actually, since they're
> meant to be updated whenever the bugs are entered into the system
> rather than from cron, but that's been a bit flakey ever since it was
> implemented so it's no real cause for concern. Adam Heath is a local
> admin for the machine hosting bugs.debian.org as well as a maintainer
> of the BTS and might have time to look into it before accounts reopen,
> but if not, it'll be fixed then. As long as the bugs themselves are
> displaying fine (bugreport.cgi / http://bugs.debian.org/nn), no
> information is being lost, and the indices can be easily recreated.

This has been fixed for a few days now, but I've only just regained
access to my mail to see this thread.

-- 
Colin Watson  [EMAIL PROTECTED]

免费发布供求信息

[商务之窗]

您好，这是一份善意的商业邮件，如本信息对您无帮助，请随手删除，并深表歉意。
---
免费发布供求信息的好去处http://www.bizwds.com  网络实名：商务之窗

为你在深圳找寻客户、合作伙伴、供应商，做24小时的网上生意！

请登录我们网站http://www.bizwds.com  网络实名：商务之窗
---
[EMAIL PROTECTED]

Re: Accounts on debian.org machines

[Scott James Remnant]

On Mon, 2003-12-08 at 03:18, Matthew Garrett wrote:

> Steve Langasek wrote:
> 
> >But an ssh key on removable media is not vulnerable to keysniffing
> >alone, where a password is.
> 
> If such behaviour becomes common, the keysniffers will simply copy
> anything that looks like an SSH key that exists on an item of removable
> media. There's no inherent increase in security from using a key on a
> USB device other than the fact that attackers aren't thinking about that
> yet.
> 
Unless you only connect the USB device for the brief period you wish to
use the content, after a "reasonable" check that your box hasn't been
compromised.

Not having the key permanently on a box is certainly better than the
opposite.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



signature.asc
Description: This is a digitally signed message part

Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)

[Brian May]

On Sun, Dec 07, 2003 at 02:02:10PM +1100, Russell Coker wrote:
> The recent versions of the package have significant problems if you want to 
> convert to or from devfs.  The Debian mkinitrd has become too complex to 
> manage so I have chosen not to bother.

This seems strange, perhaps the process is not entirely obvious,
but I wouldn't have thought it be too difficult.

However, I have been disappointed with the initrd script for Debian in
that support for autodetecting software RAID1 is poor (read:
non-existant), and while RAID1 will work if the harddisks are plugged in
exactly the same way each time, the fact remains that the configuration
is hardcoded in the initrd script so if you move all harddisks on one
RAID set to different busses (for instance), it will stop working.

This is distinct from the autodetection in the kernel that is capable of
automatically scanning all harddisks on all busses to find RAID devices.

So yes, maybe initrd/initramfs is the way of the future (I have read
proposals that would make loading modules in an initramfs compulsory for
all systems), but I think there are still a few issues that need to be
resolved first.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Building Debian Completely From Source

[Bernd Eckenfels]

On Mon, Dec 08, 2003 at 06:47:44PM -0500, Matt Zimmerman wrote:
> Yes, but building the complete Debian package is hopefully not necessary for
> bootstrapping purposes, only to get a working make binary.

So it would be wort to look at the LFS scripts, to get a minimum system boot
strapped. 

On the other side, if you use any form of external tools (and you will need
to do that unless you use the ROM debugger from IBM PCs to enter bootstrap
code), you can also use a minimal bootstrap system from cross compiler.

This would not be safe against the Thompsons trust[1] attack, but at least it
will generate a nearly completely reproduceable build environment.

Greetings
Bernd

[1] http://www.acm.org/classics/sep95/
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

LDAP gateway broken?

[John Goerzen]

I just sent my first-ever message to the LDAP gateway to reset my
password.  I got the below message back.  BTW, my clock is accurate.

I used the exact "echo" command given in the docs.

Also, I received no other reply.

What gives?

-- John

On Mon, Dec 08, 2003 at 05:14:43PM +, [EMAIL PROTECTED] wrote:
> Hello!
> 
> Your request to the mail gateway is malformed, or an internal processing
> error occured. The information below may help you, or the gateway
> administrator to identify the problem.
> 
> Error: The replay cache rejected your message. Check your clock!
> ==> Message Error: Signature has already been received
> 
> 
> Please email [EMAIL PROTECTED] if you have any questions.

Re: Building Debian Completely From Source

[Herbert Xu]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> 
> There are quite a few, but make is a bad example, as it has included a
> shell script to build itself for just this purpose.

But its debian/rules is a makefile since the policy requires it
to be so, right? :)
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: more details on the recent compromise of debian.org machines

[Andreas Barth]

Hi,

* Marc Haber ([EMAIL PROTECTED]) [031128 10:55]:
> I would like to know whether the attacker was able to log in to auric,
> even as unprivilieged user. Did she actively try to compromise auric?
> 
> What kind of verification of auric's integrity was done / is planned
> to be done?
> 
> [more questions]

Were these questions answered on debian-private, or did I miss the
answer here? I would really be interested in the answer.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Accounts on debian.org machines

[Joe Drew]

On Mon, 2003-12-08 at 15:37, David B Harris wrote:
> I've also yet to see anybody post their IP address, userid, and
> password for their publicly-accessible servers to a public mailing list
> :)

I have. root, even.

http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01187.html

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Just admit to yourself that you're a thief: http://me.woot.net/stealing.html

Re: Accounts on debian.org machines

[David B Harris]

On Mon, 08 Dec 2003 18:38:25 -0500
Joe Drew <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-12-08 at 15:37, David B Harris wrote:
> > I've also yet to see anybody post their IP address, userid, and
> > password for their publicly-accessible servers to a public mailing list
> > :)
> 
> I have. root, even.
> 
> http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01187.html

*THEIR* IP address, userid, and password. As opposed to a carefully
sandboxed userid and environment.

Or are you saying that you used [EMAIL PROTECTED] for your
computing needs, including storing your unencrypted GPG, unencrypted SSH
key (or encrypted, in which case both of which use the passwords you've
posted), your email client, your web browsing, your programming, your
work, and what have you? :)

Bug#223370: ITP: makeztxt -- Create zTXT databases from ASCII files to read them in a Palm

[Gunnar Wolf]

Package: wnpp
Severity: wishlist


* Package name: makeztxt
  Version : 1.6.0
  Upstream Author : John Gruenenfelder <[EMAIL PROTECTED]>
* URL : http://gutenpalm.sf.net/
* License : GPL
  Description : Create zTXT databases from ASCII files to read them in a 
Palm

A simple commandline program that takes a plain ASCII text file and
compresses it into a zTXT database. Makeztxt will remove newline
characters at the end of lines that contain text so that the paragraphs
flow better on the Palm screen. Makeztxt supports the use of regular
expressions to automatically generate a list of bookmarks for you.
Lastly. makeztxt can also break an existing zTXT file into its
components (text, bookmarks, annotations) and store them into separate
files.

zTXT databases can be opened by the GPLed WeaselReader program in your
Palm (http://gutenpalm.sf.net/)

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux shmate 2.4.23-shmate #1 Fri Dec 5 08:07:11 CST 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Re: Building Debian Completely From Source

[Matt Zimmerman]

On Tue, Dec 09, 2003 at 09:52:39AM +1100, Herbert Xu wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > 
> > There are quite a few, but make is a bad example, as it has included a
> > shell script to build itself for just this purpose.
> 
> But its debian/rules is a makefile since the policy requires it
> to be so, right? :)

Yes, but building the complete Debian package is hopefully not necessary for
bootstrapping purposes, only to get a working make binary.

-- 
 - mdz

Re: Need help: Idle X-user?

[David Z Maze]

Dennis Stampfer <[EMAIL PROTECTED]> writes:

> timeoutd loggs user out when they reached timeout-restrictions like max.
> login-time, max. idle-time, etc.
>
> Is there any way to querry how long a X-user is idle?

You might look at the xscreensaver driver source; the basic answer is
"yes, about four of them, none of which are guaranteed to be there".

> If not, do you think it's okay to write something like "IDLE-Logout
> does not work with X" into Readme.Debian and into the
> config-file(,manpage, ...)?

IMHO the README.Debian file and package description should be
sufficient.  Mentioning it in the man page wouldn't hurt; I think
splattering it in the config file is going a bit far.

-- 
David Maze [EMAIL PROTECTED]  http://people.debian.org/~dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
-- Abra Mitchell

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Moritz Moeller-Herrmann]

Andreas Metzler wrote:

> Billy Biggs <[EMAIL PROTECTED]> wrote:
>> Steve Greenland ([EMAIL PROTECTED]):
>>> On 04-Dec-03, 14:44 (CST), Nathanael Nerode <[EMAIL PROTECTED]>
>>> wrote:
>>> > There's now a standard used by KDE and GNOME which has more features
>>> > than the Debian menu system.
> 
>>> And missing one key one: working with menu sysems other than KDE and
>>> GNOME.
> 
>>  So far there has been a lot of support for the .desktop standard
>> effort.  Which systems do you refer to that are not supporting,
>> adopting, or intending to adopt the .desktop standard?
> 
> Have you any evidence that (or any idea whether) fvwm, icewm, wmaker,
> lwm, ...[1] plan to support .desktop?

It is trivial to support desktop in icewm. Check out icewm.py, one of my few
programming exercises.

-- 
Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain. 
(ANATOLE FRANCE)
 

Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Moritz Moeller-Herrmann]

Andrew Suffield wrote:

> On Fri, Dec 05, 2003 at 03:02:42PM +0800, Cameron Patrick wrote:

>> Except that AFAIK .desktops are still semantically richer than the
>> existing Debian system, and have more momentum behind them outside of
>> Debian.  Upstream packages are much more likely to ship to .desktop
>> files than they are Debian menu entries.  Admittedly I'm not convinced
>> that they're ready enough in other ways to replace what we have now.
> 
> Thing is, none of this matters. If upstream support .desktop files,
> then we just run them through the script that converts them to Debian
> menu entries while installing. dh_installmenu would be a good place to
> do this.

You do realize that the desktop standard has more features than the debian
menu system? Like i18n, icon theming, dynamic construction of a menu
hierarchy based on user /Desktop system preferences and so on? And that
this information would be lost? Why not run it the other way around,
convert the existing debian menu entries to .desktop files and work from
there? I think that this way would help debian on the desktops.
 
> The extra features should be pretty simple to implement - just more
> text fields.

Hardly. The desktop system in KDE-3.2+ and Gnome-2.4+ is not as static and
uncustomizable the Debian menu system at the moment.

> That way we support the upstream menu entries in
> everything, not just kde and gnome.

-- 
Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain. 
(ANATOLE FRANCE)
 

Re: Backport of the integer overflow in the brk system call

[Colin Watson]

On Thu, Dec 04, 2003 at 03:29:02PM -0800, Tom wrote:
> Just rambling... I'm sure there's tons of holes in what I just said.

All this rambling is getting pretty damn tedious as I try to read
through two weeks' worth of debian-devel backlog. Could you please try
to keep debian-devel posts to well-thought-out [1] technical content,
excluding rambling, musings on the sociology of the American South, and
other such noise, please? This is not debian-user, not that noise is
good there either with an even more rampantly enormous backlog to deal
with.

[1] Quiet down, you cynics in the peanut gallery. :)

-- 
Colin Watson  [EMAIL PROTECTED]

较完备的电子技术光盘

[新阳光单片机开发中心]

您好：

较完备的电子技术光盘
详细请进:  http://www.newsunmcu.com/gpzl.html

Bug#223403: ITP: giftui -- Graphical user interface to giFT

[Julien Delange]

Package: wnpp
Severity: wishlist

* Package name: giftui
  Version : 0.3.1
  Upstream Author : <[EMAIL PROTECTED]>
* URL : http://giftui.tuxfamily.org/
* License : GPL
  Description : Graphical user interface to giFT

gifTui is a graphical user interface to the giFT filesharing system.
It's features are: multiple "browse user" and search tabs, network
status, control uploads/downloads. gifTui uses GTK+2 library.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux evira 2.6.0-test10 #3 SMP Wed Nov 26 14:06:53 CET 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Backport of the integer overflow in the brk system call

[Colin Watson]

On Mon, Dec 08, 2003 at 01:28:20PM +1100, Russell Coker wrote:
> Another problem is that host keys require SUID ssh client in the
> default configuration.

This hasn't been true since OpenSSH 3.3, and therefore since before
woody. See ssh-keysign(8).

openssh (1:3.3p1-0.0woody1) testing-security; urgency=high

  [...]
  * Support setuid ssh-keysign binary instead of setuid ssh client.
  [...]

 -- Daniel Jacobowitz <[EMAIL PROTECTED]>  Mon, 24 Jun 2002 13:43:44 -0400

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bits from the RM

[Colin Watson]

On Thu, Dec 04, 2003 at 06:31:02PM +0100, Jan Nieuwenhuizen wrote:
> Peter S Galbraith <[EMAIL PROTECTED]> writes:
> > another package's was using convert in the build stage to convert
> > some images and it was failing.  The bug was elevated to
> > release-critical.  I don't think it would be fair to remove
> > imagemagick from the distribution for such a case.
> 
> From the other package's view, how fair was it to allow a partly
> broken version of Imagemagick enter the distribution, breaking the
> build on debian?

There are plenty of bugs that should be fixed, certainly, but not all of
them need to be release-critical.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Accounts on debian.org machines

[Niall Young]

On Mon, 8 Dec 2003, Matthew Garrett wrote:

> Steve Langasek wrote:
>
> >But an ssh key on removable media is not vulnerable to keysniffing
> >alone, where a password is.
>
> There's no inherent increase in security from using a key on a
> USB device other than the fact that attackers aren't thinking about that
> yet.

Cryptographic smart cards on a USB token seem like the only secure way
to store keys: http://www.datakey.com/products/smartCards/ikey.shtml

Niall YoungChime Communications Pty Ltd
[EMAIL PROTECTED]Level 6, 263 Adelaide Terrace
Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000

"I was trying to kill a level 5 lumberjack in the MUD I play"
-- Travis Read, August 2003

Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Andrew Suffield]

On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote:
> > On Fri, Dec 05, 2003 at 03:02:42PM +0800, Cameron Patrick wrote:
> 
> >> Except that AFAIK .desktops are still semantically richer than the
> >> existing Debian system, and have more momentum behind them outside of
> >> Debian.  Upstream packages are much more likely to ship to .desktop
> >> files than they are Debian menu entries.  Admittedly I'm not convinced
> >> that they're ready enough in other ways to replace what we have now.
> > 
> > Thing is, none of this matters. If upstream support .desktop files,
> > then we just run them through the script that converts them to Debian
> > menu entries while installing. dh_installmenu would be a good place to
> > do this.
> 
> You do realize that the desktop standard has more features than the debian
> menu system? Like i18n, icon theming, dynamic construction of a menu
> hierarchy based on user /Desktop system preferences and so on? And that
> this information would be lost? Why not run it the other way around,
> convert the existing debian menu entries to .desktop files and work from
> there? I think that this way would help debian on the desktops.

Because you gain *nothing* and introduce a pointless transition.

> > The extra features should be pretty simple to implement - just more
> > text fields.
> 
> Hardly. The desktop system in KDE-3.2+ and Gnome-2.4+ is not as static and
> uncustomizable the Debian menu system at the moment.

None of which is the problem of the menu package. It just has to read
the fields and pass them to the methods, which then write out suitable
data files for the frontend. In the case of kde/gnome, that would be a
.desktop file; for everything else, yes, the data is thrown
away. Nothing else supports those features, and this is again not our
problem.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Accounts on debian.org machines

[Russell Coker]

On Tue, 9 Dec 2003 11:04, David B Harris <[EMAIL PROTECTED]> wrote:
> Or are you saying that you used [EMAIL PROTECTED] for your
> computing needs, including storing your unencrypted GPG, unencrypted SSH
> key (or encrypted, in which case both of which use the passwords you've
> posted), your email client, your web browsing, your programming, your
> work, and what have you? :)

It wouldn't surprise me if someone did that.

ssh private keys have been installed on my play machine (never checked whether 
they were specially generated for my play machine or copied from somewhere 
else), people have used it to ssh and scp to root accounts on other servers 
(which presumably are not SE Linux play machines), people have logged in with 
X11 and xauth forwarding enabled.

One time someone claimed to have broken the security of my play machine by 
writing a shell script to "kill -1" the shells of other users.  However they 
had apparently enabled X11 forwarding...

Incidentally the adsl.coker.com.au host disappeared 9 months ago when I 
switched from Amsterdam ADSL to Melbourne Cable.  The details of my new play 
machine are linked from my .sig.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page