Re: For Those Who Care About: Switzerland/Liechtenstein
Adrian von Bidder wrote: > On Friday 02 February 2007 09:33, Sam Hocevar wrote: > > On Fri, Feb 02, 2007, martin f krafft wrote: > > > PS: Almost all... as first official act, I herewith announce the > > > nomination of Mark J. Ray as an honorary member of debian.ch. > > > Honorary members have no rights and no obligations, but they also > > > cannot quit. > > > >Is that legal? > > No it's not. It's what we technically call a Joke. Debian could use more > of them. (And yes, I do invite people to make jokes on my expense when the > occasion arises.) While I agree that it could help improve the discussion culture if more jokes would be made in Debian, I reject the idea that they should be made of cost of others, MJ Ray in this case. Make the Tux an honorary member, that would've been fine. This is just an insult. Regards, Joey -- All language designers are arrogant. Goes with the territory... -- Larry Wall Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For Those Who Care About: Switzerland/Liechtenstein
On Saturday 03 February 2007 20:25, Joey Schulze <[EMAIL PROTECTED]> wrote: > > No it's not. It's what we technically call a Joke. Debian could use > > more of them. (And yes, I do invite people to make jokes on my expense > > when the occasion arises.) > > While I agree that it could help improve the discussion culture if > more jokes would be made in Debian, I reject the idea that they should > be made of cost of others, MJ Ray in this case. Make the Tux an > honorary member, that would've been fine. This is just an insult. What was insulting about this? Is MJ known to have a great dislike of Switzerland or is there any other reason to believe that he would be offended by such a joke? I hereby create the Informal Debian Developers society and name MJ Ray as the first honorary member. Honorary members can't quit! ;) -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
Re: Attempts at security
Am Freitag 02 Februar 2007 21:14 schrieb Reinhard Tartler: > Hendrik Sattler <[EMAIL PROTECTED]> writes: > > And everybody gets the SE Linux overhead if he wants or not? > > Which overhead does SE Linux impose to you? Take a look at the extra paths in the LSM that the kernel runs for many system calls. There is no selective choice in what to turn on, except the rules that you specify later down that road. ALthough capabilities also use the LSM (which sucks, btw), the are pretty simple (this is _not_ a comparison to SE Linux). > > The current system does not give you perfect security but neither does > > adding SE Linux. Instead, you probably get annoying permission > > problems. > > Name a few guys that really likes to use this on a private machine and > > some real-life improvements that it brings. Hint: "increased security" is > > not an argument. > > I consider "increased security" a very valid argument. The DAC security > model is quite outdated now and doesn't really match real world security > concerns most workstations are experiencing today! "Real world security concerns"? Please describe your "real world" and compare to the other existant "real world"s. > > Not being able to change the cause to the better doesn't mean to > > introduce a mess to control the result. And I really hope that Debian > > never considers installing+enabling selinux by default. > > IIRC, debian/etch already does already install selinux today without you > even noticing it. It is not enabled by default. That is the other point: you get that selinux integration if you want or not. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security
On Saturday 03 February 2007 22:37, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > Am Freitag 02 Februar 2007 21:14 schrieb Reinhard Tartler: > > Hendrik Sattler <[EMAIL PROTECTED]> writes: > > > And everybody gets the SE Linux overhead if he wants or not? > > > > Which overhead does SE Linux impose to you? > > Take a look at the extra paths in the LSM that the kernel runs for many > system calls. There is no selective choice in what to turn on, except the > rules that you specify later down that road. > ALthough capabilities also use the LSM (which sucks, btw), the are pretty > simple (this is _not_ a comparison to SE Linux). It would be interesting to do some benchmarks and compare the overhead of a LSM kernel booted without SE Linux enabled to some of the other overheads we have. One that springs to mind is CONFIG_HIGHMEM4G, it seems only useful if you have more than 896M of RAM. Therefore it seems that all P3 desktop machines with the i686 kernel package from etch will receive no benefit from it (I am not aware of any P3 desktop machine that supports more than 512M of RAM). Another is the fact that all Debian kernels for i686 and similar CPUs are compiled with SMP enabled even though the vast majority of such machines are not SMP. Until the most recent developments in CPUs implementing the AMD64 ISA SMP on the desktop was extremely rare (and desktops outnumber servers by a significant margin). While an occasional branch statement that is not taken may impose a tiny overhead, it's nothing compared to having a sub-optimal memory arrangement or having extra locks for SMP. This is not to criticise those choices of the kernel team. Having a smaller number of kernels makes the entire build and support process easier - which benefits all of us in many non-obvious ways. Anyway, if the overhead of SE Linux in the kernel is something you consider to be a problem then there are many bigger problems that you will have with the Debian kernel packages (or probably any kernel image from a binary distribution). Best to just compile your own kernel. > > > The current system does not give you perfect security but neither does > > > adding SE Linux. Instead, you probably get annoying permission > > > problems. > > > Name a few guys that really likes to use this on a private machine and > > > some real-life improvements that it brings. Hint: "increased security" > > > is not an argument. > > > > I consider "increased security" a very valid argument. The DAC security > > model is quite outdated now and doesn't really match real world security > > concerns most workstations are experiencing today! > > "Real world security concerns"? Please describe your "real world" and > compare to the other existant "real world"s. Do you have any specific objections to Reinhard's statement? Making ad-hominem attacks on someone else's grasp of reality doesn't help the discussion. Do you even know what DAC is and what it's failings are? > > > Not being able to change the cause to the better doesn't mean to > > > introduce a mess to control the result. And I really hope that Debian > > > never considers installing+enabling selinux by default. > > > > IIRC, debian/etch already does already install selinux today without you > > even noticing it. > > It is not enabled by default. That is the other point: you get that selinux > integration if you want or not. Apart from those branch instructions in the kernel image what specific things do you object to? -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
Am Samstag 03 Februar 2007 02:21 schrieb Russell Coker: > On Saturday 03 February 2007 05:17, Hendrik Sattler > <[EMAIL PROTECTED]> wrote: > > And everybody gets the SE Linux overhead if he wants or not? > > It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux > where it's on by default. I believe that the latest release of SUSE has > AppArmor on by default. RedHat has a long history of strange decisions. > > The current > > system does not give you perfect security but neither does adding SE > > Linux. Instead, you probably get annoying permission problems. > > This is why every Windows user uses the administrator account for > everything. No, this is caused by other system design flaws and some bad software companies. Some learned and improved (Nero) and some didn't (Epson). But Microsoft probably had reason why they hide the file system ACL settings by default (hint: complexity). > > > You want features such as exec-shield, well you don't get them - > > > because of other people with the same attitude as you. > > > > Please differ between things that are pretty much automatic (even when > > not only using debian packages) and things that you need some days to > > setup correctly (if you ever manage to do so). > > And always think about the problems that you introduce with such things > > (and almost all you named have such). > > You claim that almost all the examples I gave have problems. Please > explain the problems that you believe to be in exec-shield, PIE, and > poly-instantiated directories. Make sure that they are real examples not > "a program might have some problem" claims. PIE: http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.html Does X already work with it? Mplayer is also name there and thus probably xine (using these win32-DLLs), too? How about things like Mono? Exec-shield is related to it, AFAIK. Since this is selective for every application, it is good. But everything that increases restrictions of whatever kind will hit a project that cannot handle this restriction. Not naming those in the same spot as advertising it does not really help... But you are right, most users and even programmers will never notice... For the poly-instantiated views to directories, I am not sure that this is thought to its end, yet. The main usage will probably be /tmp but there are already solutions for secure temp file creation. Although it can integrate with SE Linux, it does not require it. Users may get confused why they do not see the same directory contents althought the path is the same. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security
Am Samstag 03 Februar 2007 13:17 schrieb Russell Coker: > Anyway, if the overhead of SE Linux in the kernel is something you consider > to be a problem then there are many bigger problems that you will have with > the Debian kernel packages (or probably any kernel image from a binary > distribution). Best to just compile your own kernel. At some point they just add. I don't have a problem compiling my own kernels but is there any site describing use case scenarios for selinux and also consider to not use it for some scenarios? It's just that I am pretty sure that I do not need it. However, using the term "security" seems to set a flag in some minds that somehow implies the idea of getting it to everyone, needed or not. Is it that strange to raise a flag and keep saying that there are some that don't need it and don't want it? Typical example in _my_ case are selinux and fine grained file system extended ACLs. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security
On la, 2007-02-03 at 12:37 +0100, Hendrik Sattler wrote: > > > Not being able to change the cause to the better doesn't mean to > > > introduce a mess to control the result. And I really hope that Debian > > > never considers installing+enabling selinux by default. > > > > IIRC, debian/etch already does already install selinux today without you > > even noticing it. > > It is not enabled by default. That is the other point: you get that selinux > integration if you want or not. Debian has made similar decisions throughout its history: we generally don't provide separate X and non-X versions of the same package, for packages where this is a build time option, for example. That is also a cost every Debian user pays: increased disk and memory usage, even if they don't use X at all. In order to keep the complexity of the entire Debian system manageable, we need to make those choices. If we, as a project, are of the opinion that providing SELinux support is a good thing, then everything in Debian that needs to be changed for the support to exist needs to be changed, even if the individual maintainer thinks SELinux isn't useful. The mechanism we have for deciding such policy issues is the policy document, the -policy list, and the associated procedures for proposing and accepting changes to the policy. Enabling SELinux by default obviously shouldn't happen until it can be done without disturbing most people's use of Debian. As far as I know, that should be possible to achieve, though. -- I've never seen anyone wear a Freudian slip. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security
On Sat, 03 Feb 2007, Russell Coker wrote: > One that springs to mind is CONFIG_HIGHMEM4G, it seems only useful if you > have You need to enable PAE (64GB support) to access the NX bit on ia32, which is even worse, and that's the reason why my 1GB laptop has a PAE kernel :( > Another is the fact that all Debian kernels for i686 and similar CPUs are > compiled with SMP enabled even though the vast majority of such machines are > not SMP. Until the most recent developments in CPUs implementing the AMD64 Nowadays the kernel patches itself at runtime, I believe, to reduce the cost of SMP on UP. But your point stands, anyway. Heck, use of ECC memory can slow down a system by as much as 1% AFAIK, and still, use of ECC is pretty much a given everywhere people really cares about stability (e.g. you cannot even buy servers from non-joke vendors without chipkill memory...) > Anyway, if the overhead of SE Linux in the kernel is something you consider > to > be a problem then there are many bigger problems that you will have with the If the overhead is really big, we can have SE Linux in the kernel as an optional component. But it isn't that big when the thing is off. It *is* quite measurable when it is ON and enforcing policy, but since we are not talking about whether to enable it by default or not, or even how to word the question asking the user whether he want it enabled or not, THAT is not the point. > Debian kernel packages (or probably any kernel image from a binary > distribution). Best to just compile your own kernel. Agreed. > > "Real world security concerns"? Please describe your "real world" and > > compare to the other existant "real world"s. Botnets and the mafias behind them. Trojans. Script kiddies. > > It is not enabled by default. That is the other point: you get that selinux > > integration if you want or not. Yes, and exactly what is the problem with that? Have you *ever* looked at the ammount of libraries we link to in Debian? SE Linux libs are small compared to most of them, and *far* more useful. SE Linux is really just an extra library and files laying around in your HD, as long as you compile your own kernel. And if you don't compile your own kernel, its impact is very minimal while disabled *and* you are in no position to argue anything about performance, as the Debian kernel config is anything BUT engineered for performance anyway (e.g. everything is a module). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/07 08:20, Henrique de Moraes Holschuh wrote: > On Sat, 03 Feb 2007, Russell Coker wrote: [snip] >>> "Real world security concerns"? Please describe your "real world" and >>> compare to the other existant "real world"s. > > Botnets and the mafias behind them. Trojans. Script kiddies. I definitely know that there are Linux rootkits (sneak in via bugs in ssh, PHP & MySQL, and kernel bugs?), but how pervasive are *infected* Linux machines? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFxKU8S9HxQb37XmcRAqZ/AJ9uCmpn1VPzIzoecfiIUGMfxGwujQCgubBV Kdmxr2m8Z85wB0HOElVLBUA= =EQJQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/foo has been mounted xx times... check forced
Hello, the feature as in the subject is nice and makes me feel safe, but sometimes it hits on the laptop, when booting on batteries, with people watching. Ideally, if I'm in a hurry I would like to be able to do ^C on it, and I would expect that the same check is run at next boot; however, I never dare doing it. Assuming it's safe to ^C fsck, would it make sense to change the message to document it, like: /foo has been mounted xx times [...] check forced If you need to boot quickly, you can safely interrupt with ^C and postpone the check to the next startup. Or are there better fsck strategies? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /foo has been mounted xx times... check forced
On Saturday 03 February 2007 10:39, Enrico Zini wrote: > Assuming it's safe to ^C fsck, would it make sense to change the > message to document it, like: In my experience it is safe, except when the / partition is being fsck'ed. For / it is also safe, but I've been unable to get the system to boot normally before first completing the fsck. IIRC, it will reboot and then happily start fcsk'ing again. pgp8eaG4xA2vg.pgp Description: PGP signature
Re: /foo has been mounted xx times... check forced
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/07 03:39, Enrico Zini wrote: > Hello, > > the feature as in the subject is nice and makes me feel safe, but > sometimes it hits on the laptop, when booting on batteries, with people > watching. > > Ideally, if I'm in a hurry I would like to be able to do ^C on it, and I > would expect that the same check is run at next boot; however, I never > dare doing it. > > Assuming it's safe to ^C fsck, would it make sense to change the message > to document it, like: > > /foo has been mounted xx times [...] check forced > If you need to boot quickly, you can safely interrupt with ^C and > postpone the check to the next startup. > > Or are there better fsck strategies? The file /etc/init.d/checkfs.sh (in package initscripts) is supposed to check whether you are on battery power or not. Maybe a bug needs to be filed against it? Also according to /etc/init.d/checkfs.sh, the existence of the file /fastboot should prevent fsck. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFxNYqS9HxQb37XmcRAnYXAJ9q9QpaaYIFXk3AWX7sIF0ox9FsQgCfRg66 9kUxXl/lO9LQwtSVlmCknN0= =VaZt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /foo has been mounted xx times... check forced
Hi, * Ron Johnson <[EMAIL PROTECTED]> [2007-02-03 20:13]: > On 02/03/07 03:39, Enrico Zini wrote: [...] > > Assuming it's safe to ^C fsck, would it make sense to change the message > > to document it, like: > > > > /foo has been mounted xx times [...] check forced > > If you need to boot quickly, you can safely interrupt with ^C and > > postpone the check to the next startup. > > > > Or are there better fsck strategies? > > The file /etc/init.d/checkfs.sh (in package initscripts) is supposed > to check whether you are on battery power or not. Maybe a bug needs > to be filed against it? That would be a problem since not every laptop supports apm or acpi properly. Could be also possible that needed kernel modules for this (have not checked this) are not already loaded when the script is started. Kind regards Nico -- Nico Golde - http://www.ngolde.de JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF Forget about that mouse with 3/4/5 buttons, gimme a keyboard with 103/104/105 keys! pgprgograK5zM.pgp Description: PGP signature
Bug#409526: ITP: shell.fm -- console based player for last.fm radio streams
Package: wnpp Severity: wishlist Owner: Nacho Barrientos Arias <[EMAIL PROTECTED]> * Package name: shell.fm Version : 0.2 Upstream Author : Jonas Kramer <[EMAIL PROTECTED]> and others. * URL : http://nex.scrapping.cc/shell-fm/ * License : GPL Programming Lang: C Description : console based player for last.fm radio streams Shell.FM is a lightweight and interactive console based player for last.fm radio streams, e.g. lastfm://artistnames/someartist. . Homepage: http://nex.scrapping.cc/shell-fm/ - Maintainer notes: Upstream is currently working in switching from OpenSSL to libgcrypt (or something like that), so I won't work on this package until this transition is complete. Regarding source version, I will probably upload a SVN snapshot. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /foo has been mounted xx times... check forced
Ron Johnson wrote: > The file /etc/init.d/checkfs.sh (in package initscripts) is supposed > to check whether you are on battery power or not. Maybe a bug needs > to be filed against it? Assumption: This only works, if the battery module is loaded at this point. Normally acpid loads this module, which is to late in the boot process. /Armin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /foo has been mounted xx times... check forced
Hi, * Armin Berres <[EMAIL PROTECTED]> [2007-02-03 21:32]: > Ron Johnson wrote: > > The file /etc/init.d/checkfs.sh (in package initscripts) is supposed > > to check whether you are on battery power or not. Maybe a bug needs > > to be filed against it? > > Assumption: This only works, if the battery module is loaded at this > point. Normally acpid loads this module, which is to late in the boot > process. Acpid doesn't load modules, it only listens to events and executes programs. Kind regards Nico -- Nico Golde - http://www.ngolde.de JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF Forget about that mouse with 3/4/5 buttons, gimme a keyboard with 103/104/105 keys! pgpQtEdDKJbnL.pgp Description: PGP signature
Re: /foo has been mounted xx times... check forced
On Sat, 3 Feb 2007 21:45:49 +0100 Nico Golde wrote:
> Acpid doesn't load modules, it only listens to events and
> executes programs.
But the init-script does:
# As the name says. If the kernel supports modules, it'll try to load
# the ones listed in "MODULES".
load_modules() {
...
}
Regards
--
^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED])
d(O_o)b | PGP-Key-ID: 0xAC15B50C
>-|-< | WWW: http://www.die-welt.net ICQ: 54116744
/ \| IRC: #sod @ irc.german-freakz.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /foo has been mounted xx times... check forced
Hello! On Sat, 03 Feb 2007 21:45:49 +0100, Nico Golde wrote: > * Armin Berres <[EMAIL PROTECTED]> [2007-02-03 21:32]: >> Ron Johnson wrote: >>> The file /etc/init.d/checkfs.sh (in package initscripts) is >>> supposed to check whether you are on battery power or not. Maybe >>> a bug needs to be filed against it? >> >> Assumption: This only works, if the battery module is loaded at >> this point. Normally acpid loads this module, which is to late in >> the boot process. > > Acpid doesn't load modules, it only listens to events and executes > programs. This is not completely true, because the Debian acpid init scripts loads modules, as per /etc/default/acpid: = # Specify modules to load on acpid's startup # MODULES may be uncommented to load "none", contain the string "all" # to load all acpi related modules or simply a space seperated list # of modules to be probed. MODULES="battery ac processor button fan thermal" = Thx, bye, Gismo / Luca pgpSaioLtuUhF.pgp Description: PGP signature
Re: /foo has been mounted xx times... check forced
Evgeni Golov wrote: > On Sat, 3 Feb 2007 21:45:49 +0100 Nico Golde wrote: > >> Acpid doesn't load modules, it only listens to events and >> executes programs. > > But the init-script does: That's what I meant. Thanks for the clarification. I can confirm the following behavior: If I boot with a stock debian kernel fsck is run even if I'm on battery. If I boot with a self compiled kernel which has the acpi modules built in, fsck isn't executed, if I'm on battery. /Armin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409544: ITP: tripod -- iPod photo uploader
Package: wnpp Severity: wishlist Owner: Mark Purcell <[EMAIL PROTECTED]> * Package name: tripod Version : 0.7.0 Upstream Author : Seb Ruiz <[EMAIL PROTECTED]> * URL : http://www.sebruiz.net/tripod * License : GPL Programming Lang: C++ Description : iPod photo uploader Tripod makes transferring photos to your iPod a breeze! Plug it in, select some images and upload them! Tripod allows for creating, deleting and renaming photo albums, as well as transferal of photos, obviously. This package provides similar functionality to the iPodExport plugin within the kipi-plugins package, indeed they are written by the same upstream author. kipi-plugins has the advantage of working with the digikam, showimg, kphotoalbum and gwenview applications. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (700, 'unstable'), (650, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409553: ITP: ttf2tex -- a TrueType font installer for Unix
Package: wnpp Severity: wishlist Owner: Rafael Laboissiere <[EMAIL PROTECTED]> * Package name: ttf2tex Version : 0.70 Upstream Author : Philipp Lehman <[EMAIL PROTECTED]> * URL : http://www.ctan.org/tex-archive/help/Catalogue/entries/ttf2tex.html * License : GPL Programming Lang: Bash shell Description : a TrueType font installer for Unix ttf2tex is a script for the Bash shell which generates all files required to use TrueType fonts with teTeX or TeX Live from a set of font files. In short, it will do for fonts what fontinst's latinfamily command does for Type 1 PostScript fonts. In addition to that, ttf2tex sorts all files, builds the map files required by ttf2pk and pdftex, and optionally installs everything into either the system-wide local TeX tree or the private TeX tree of the user running ttf2tex. Note that ttf2tex's approach to using TrueType fonts with TeX does not imply converting them to Type 1 format. With a current version of teTeX and a proper setup, TeX can use TrueType fonts via the ttf2pk utility while pdftex even supports them natively. This package includes a tool for creating a Debian package for use in latex or pdflatex from a family of TT fonts in the file system (ttf2tex-mkpkg). Notice that ttf2tex is not being supported upstream since September 2004. However, the command seems to be stable and robust. A preliminary version of the package is available in [1], where you can also find a package automatically generated with ttf2tex-mkpkg (latex-dkghwr-font). The TTF files for creating this package are in the ttf-fifthhorseman-dkg-handwriting, which is in the NEW queue. After installing this package, a LaTeX file as simple as [2] can be used in pdflatex to produce DVI or PDF files [3]. [1] http://people.debian.org/~rafael/ttf2tex/ [2] http://people.debian.org/~rafael/ttf2tex/test.tex [3] http://people.debian.org/~rafael/ttf2tex/test.pdf -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader
Package: wnpp Owner: Luca Capello <[EMAIL PROTECTED]> Severity: wishlist * Package name: thinkfinger Version : 0.2.2 [1] Upstream Author : Timo Hoenig <[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]> * URL or Web page : http://thinkfinger.sourceforge.net * License : GPL Description : $PACKAGE for the SGS Thomson Microelectronics fingerprint reader ThinkFinger is a driver for the UPEK/SGS Thomson Microelectronics fingerprint reader. The device is being found either as a standalone USB device, built into USB keyboards or built into laptops (usually From Dell, IBM/Lenovo and Toshiba). Here it will be the second part of the long description, read below. Moreover, $PACKAGE in the short description will reflect the package contents [2]. ThinkFinger is devided into two parts: libthinkfinger and pam_thinkfinger. libthinkfinger is a library to be used in order to communicate with the fingerprint reader. The utility 'tf-tool' can be used to acquire and to verify fingerprints. Now, I don't really know the best way to package ThinkFinger. In theory, I guess we should have (file size in bytes, not stripped): - libthinkfinger, depends on libusb /usr/lib/libthinkfinger.so (31751) - libthinkfinger-dev /usr/include/libthinkfinger.h (4732) /usr/lib/libthinkfinger.a (40484) /usr/lib/libthinkfinger.la (876) /usr/lib/pkgconfig/libthinkfinger.pc (324) - tf-tool, depends on libthinkfinger /usr/sbin/tf-tool (23152) /usr/share/man/man1/tf-tool.1.gz (1052) - libpam-thinkfinger, depends on libthinkfinger [3] /etc/pam_thinkfinger/ [where the login fingerprint are stored] /lib/security/pam_thinkfinger.so (27724) /usr/share/man/man8/pam_thinkfinger.8.gz (782) Am I correct? Is tf-tool worth a single package or can I include it in libthinkfinger (as I'd prefer)? Thx, bye, Gismo / Luca Footnotes: [1] the package version will be greater than 0.2.2, because I'll wait for the inclusion of the manpages as of http://thread.gmane.org/gmane.linux.drivers.thinkfinger/111 [2] I still have a problem, because e.g. "PAM module for the SGS Thomson Microelectronics fingerprint reader" is longer than the expected 60 characters for the short description. Suggestions welcome! [3] strictly speaking, the PAM module doesn't depend on tf-tool, because it uses libthinkfinger to access the fingerprint reader. However, it should recommends tf-tool because the latter is necessary to acquire the fingerprint for a login user pgp1ZO6k0qTN5.pgp Description: PGP signature
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Saturday 03 February 2007 23:47, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > > It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux > > where it's on by default. I believe that the latest release of SUSE has > > AppArmor on by default. > > RedHat has a long history of strange decisions. Red Hat has a long history of making Linux easy to use. Try using Fedora and Debian for the same sys-admin tasks and compare. You will discover that right from the install Fedora is a lot easier. Of course the Debian installer gives many options that the Fedora installer doesn't (degraded RAID arrays and encrypted block devices as two examples), but it's a lot harder to use. The "targeted" SE Linux policy was developed because the "strict" policy was too difficult to use for most of the Fedora user-base. > > You claim that almost all the examples I gave have problems. Please > > explain the problems that you believe to be in exec-shield, PIE, and > > poly-instantiated directories. Make sure that they are real examples not > > "a program might have some problem" claims. > > PIE: > http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.htm >l Does X already work with it? Mplayer is also name there and thus probably > xine (using these win32-DLLs), too? How about things like Mono? I don't recall anyone seriously suggesting compiling all programs with PIE, just the ones that are likely to be attacked. Mplayer does many nasty things (such as loading Windows DLLs). You can expect it to have problems that other programs don't have. > Exec-shield is related to it, AFAIK. Not really. > For the poly-instantiated views to directories, I am not sure that this is > thought to its end, yet. It's been around in various forms for more than 10 years, people have thought about it a lot. > The main usage will probably be /tmp but there are > already solutions for secure temp file creation. http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html There aren't any other solutions to the problems that are solved by PI-directories. Read my paper from the above URL and see if you can discover another solution. > Users may get confused why they do not see the same directory contents > althought the path is the same. Generally with PI-directories a user doesn't have the opportunity to see different views of the same directory so this isn't a problem. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security
On Sunday 04 February 2007 01:20, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Sat, 03 Feb 2007, Russell Coker wrote: > > One that springs to mind is CONFIG_HIGHMEM4G, it seems only useful if you > > have > > You need to enable PAE (64GB support) to access the NX bit on ia32, which > is even worse, and that's the reason why my 1GB laptop has a PAE kernel :( My impression (after a quick google search) is that only applies when running a 32bit kernel on a 64bit CPU. Best to just run an AMD64 kernel and have NX without any problems. As an AMD64 kernel runs 32bit binaries, if you want a 32bit user-space why not run a 64bit kernel anyway? > Heck, use of ECC memory can slow down a system by as much as 1% AFAIK, and > still, use of ECC is pretty much a given everywhere people really cares > about stability (e.g. you cannot even buy servers from non-joke vendors > without chipkill memory...) I wasn't aware of a 1% slowdown, however I have observed that the vendors that ship ECC systems tend to ship them some months after equivalent machines are available in non-ECC versions. Being 3-6 months behind the cutting edge of technology is effectively more than a 1% loss. > It *is* quite measurable when it is ON and enforcing policy, but since we Measurable being as much as 5% depending on what you do (usually significantly less than 5%). > > > It is not enabled by default. That is the other point: you get that > > > selinux integration if you want or not. > > Yes, and exactly what is the problem with that? > > Have you *ever* looked at the ammount of libraries we link to in Debian? > SE Linux libs are small compared to most of them, and *far* more useful. Maybe the people who complain about SE Linux overhead would be better off using Gentoo. With Gentoo you can turn off every option that you don't need. This gets you the minimal installed size for everything and also means that you can discover exciting new bugs that other people haven't discovered. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Welcome to Gay.com!
idid'nt received my verification code, please send it Thanks _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security
On Sun, 04 Feb 2007, Russell Coker wrote: > On Sunday 04 February 2007 01:20, Henrique de Moraes Holschuh <[EMAIL > PROTECTED]> > wrote: > > On Sat, 03 Feb 2007, Russell Coker wrote: > > > One that springs to mind is CONFIG_HIGHMEM4G, it seems only useful if you > > > have > > > > You need to enable PAE (64GB support) to access the NX bit on ia32, which > > is even worse, and that's the reason why my 1GB laptop has a PAE kernel :( > > My impression (after a quick google search) is that only applies when running > a 32bit kernel on a 64bit CPU. Best to just run an AMD64 kernel and have NX > without any problems. Also for 32 bits on a 32 bit CPU, which is my case. ia32 is not only the 32bits mode of a 64-bit processor. It is the old i386...i686 arches too. So I happen to not HAVE amd64 hardware in the laptop, at all :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nsswitch.conf
Hello, Is it still the case that packages should not update /etc/nsswitch.conf as documented in bug #78110? The reason I ask is because libnss-mdns does just this (e.g. see bug #406198), and I thought this was a policy violation. My personal opinion is that I consider /etc/nsswitch.conf, like /etc/network/interfaces, a file reserved for local administrators and changing the fundamental polices of the computer because some package the administrator never heard of before was automatically pulled into the upgrade process is not a good thing. (not to mention mdns breaks anybody who used the recommendations of a draft Internet standard[1] to name local computers as documented already in numerous bug reports) If it is now considered OK to update /etc/nsswitch.conf, could somebody please point me to references? Thanks. Notes [1] http://www3.ietf.org/proceedings/98aug/I-D/draft-ietf-dnsind-local-names-05.txt Yes - I know - it has expired - the only other standard I know of that reserves top level domains though is RFC2606[2], and I don't consider it appropriate any of these for a local computer network. [2] http://www.faqs.org/rfcs/rfc2606.html -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Sun, Feb 04, 2007 at 12:27:41PM +1100, Russell Coker wrote: > On Saturday 03 February 2007 23:47, Hendrik Sattler > <[EMAIL PROTECTED]> wrote: > > > It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux > > > where it's on by default. I believe that the latest release of SUSE has > > > AppArmor on by default. > > RedHat has a long history of strange decisions. > Red Hat has a long history of making Linux easy to use. Try using Fedora and > Debian for the same sys-admin tasks and compare. You will discover that > right from the install Fedora is a lot easier. Of course the Debian > installer gives many options that the Fedora installer doesn't (degraded RAID > arrays and encrypted block devices as two examples), but it's a lot harder to > use. Any chance we could stick to arguing the technical case for SELinux, instead of inviting the thread to be further derailed in response to FUD about the usability of the Debian installer? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
