Re: seeding /dev/random from a security key
Jeffrey Walton wrote:
> For what you want to do, and if I am parsing it correctly... I would
> write a daemon in C [...]
Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
somehow. Writing and compiling a daemon is no less work than compiling
an already written daemon.
> The part about extracting the entropy from the source would use
> OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
> libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}.
RNGD 6 actually uses OpenSC's libp11, where it calls the function
PKCS11_generate_random, which in turn calls the PKCS #11 function
C_GenerateRandom.
Björn Persson
pgpOK5m0QGWIe.pgp
Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
Jeffrey Walton wrote:
> Out of morbid curiosity, what hardware are the servers using? RDRAND
> and RDSEED have been available since about 2012, so it is mostly
> ubiquitous nowadays.
Do you mean I should add to the e-waste pile by throwing away working
hardware and buy an entire new computer instead of buying a tiny dongle?
> Be careful of rng-tools. It does not do a good job for non-mainstream
> generators, like VIA's Padlock Security Engine. And rng-tools did not
> support generators for architectures, like you would find on ARM,
> aarch64 and PowerPC.
I figure it can be used with devices it supports even if there are some
other devices it doesn't support – but it looks like I'd have to build
it from source myself.
> OpenSSL and GnuPG should be
> able to extract the entropy from the card, and then use it to seed
> /dev/{u}random.
This job requires a daemon. OpenSSL is a library. Or do you mean its
command-line tool? So how would I tell that to fetch random data
through PKCS #11?
GnuPG at least has a daemon called scdaemon. Is that what you mean? So
how would I tell that to fetch random data through PKCS #11 and write
to /dev/random?
Björn Persson
pgpia22PvZ5bD.pgp
Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
Andy Smith wrote: > EntropyKey is a dead product that can no longer be obtained I've seen several like that. They're permanently sold out, or the webshops are abandoned and half-broken. Pure random number generators that are actually possible to buy are rare. That's why I'm investigating whether security keys can be used instead. Security keys are available from multiple vendors, but it's hard to find any information about the random number generators inside them. > OneRNG is still in production. I tried to buy one of those a while ago, but I couldn't because the shop didn't like my card number. > On their mailing list however, there > is a recent discussion about whether there any point. The conclusion > seems to be "not really". Thread starts here: > > http://lists.ourshack.com/pipermail/discuss/2024-March/000797.html > > The thread covers how to make rngd feed /dev/random from a OneRNG in > Debian 12, but it is no longer possible to tell if that does > anything useful. It is indeed harder to tell since Linux stopped keeping track of the entropy level, and it's now necessary to force-feed /dev/random periodically instead of waiting for the entropy level to drop. A random number generator is still useful on a server with no keyboard, no spinning disk and no RDRAND or similar processor instruction. Otherwise network traffic becomes the only source of entropy, and I'd rather not rely solely on events controlled by other computers. It also helps to mix entropy from multiple sources, in case one of them has a design flaw or a backdoor, or breaks down, or loses its driver like in Debian bug 1041007. Björn Persson pgpEuWy2nx_ME.pgp Description: OpenPGP digital signatur
seeding /dev/random from a security key
Hello! In a quest to acquire hardware random number generators for seeding /dev/random on servers that lack a built-in entropy source, I'm investigating how random data can be obtained from a security key such as a Nitrokey, Yubikey or a similar device. RNGD version 6 from https://github.com/nhorman/rng-tools can fetch random data through a PKCS #11 interface, but the two versions of RNGD in Debian seem to lack that ability. Debian has rng-tools5 and rng-tools-debian, but not Neil Horman's version 6. Or am I just failing to find it? SCDrand from https://incenp.org/dvlpt/scdtools.html can also obtain random data from a "smartcard"-compatible device, but I don't find that in Debian either. Does anyone know of another way to obtain random data from devices of this kind? Björn Persson pgp1OCs1ezY_B.pgp Description: OpenPGP digital signatur
Re: random number generator missing after upgrade
davidson wrote: > Debian Bug #1041007 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041007#10 Yes, that seems to be exactly my problem. So it's not intentionally disabled. Then I can hope that it may be fixed some day. Thanks for your help. Björn Persson pgpRmFKPdRagm.pgp Description: OpenPGP digital signatur
Re: random number generator missing after upgrade
David Wright wrote: > On Mon 14 Aug 2023 at 11:26:13 (+0200), Björn Persson wrote: > > Other functions in the same source file create /dev/tpm0, and it looks > > like the random number generator should get registered together with > > the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check > > the value of that option? > > $ grep CONFIG_HW_RANDOM_TPM /boot/config-5.10.0-2* > /boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y > /boot/config-5.10.0-24-amd64:CONFIG_HW_RANDOM_TPM=y > $ Thanks. And look at that: # grep CONFIG_HW_RANDOM_TPM /boot/config-* /boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y # grep CONFIG_HW_RANDOM_TPM /boot/config-6.1.0-11-amd64 ; echo $? 1 So apparently randomness from a TPM is completely disabled in Debian 12 regardless of manufacturer. Next question: Why? Björn Persson pgppuJfr4uqri.pgp Description: OpenPGP digital signatur
Re: random number generator missing after upgrade
Anders Andersson wrote: > On Sun, Aug 13, 2023 at 11:09 PM Björn Persson wrote: > > Jeffrey Walton wrote: > > > Maybe related to > > > https://www.phoronix.com/news/Linux-Disables-RNG-AMD-fTPMs > > > > Not likely. That article is about a firmware TPM that comes with newer > > Ryzen processors. Older Ryzens supposedly don't have it. The processor > > in my APU2 is a GX-412TC, not a Ryzen at all, and my TPM is a discrete > > chip from Infineon. The change in question is supposed to disable the > > random number generator only if the TPM lists AMD as its manufacturer. > > I agree that the patch looks ok, but I remember being hit by a kernel > change that inadvertently changed the behavior on other systems too > (ECC RAM background scrubbing), but nobody really noticed because it > was not in much use. > > I suspect that the case of having an external TPM on an AMD system is > such an unusual case, and I couldn't trace exactly where that patch > checked the AMD string, so perhaps it's picking up the AMD string > earlier on, and decides to disable all TPM on the AMD system. At least > the timing of the problem and the patch is suspicious. I see the 6.1 branch contains the first attempt at working around the stutter problem, which disables randomness only from certain known broken firmware versions: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c?h=linux-6.1.y#n510 It's supposed to log a warning when it takes effect: "AMD fTPM version 0x%llx causes system stutter; hwrng disabled\n" That message does not appear in my logs. The new workaround, which disables randomness from all AMD firmware TPUs and doesn't log, can be in effect only if it has been backported to Debian's kernel very recently. That does not seem to be the case, if this is the right way to look for backports: https://salsa.debian.org/kernel-team/linux/-/commits/bookworm/ I'll check what the manufacturer number is on my system, if I can figure out how to get at it. Björn Persson pgp1FtuqAK5To.pgp Description: OpenPGP digital signatur
Re: random number generator missing after upgrade
Dan Ritter wrote: > OK, either boot to the old kernel and look for an rng kernel > module, The only loaded module with "rng" in its name is "rng_core". That one is present in both kernels, but four TPM-related modules are absent from Linux 6.1: # uname -v #1 SMP Debian 5.10.179-3 (2023-07-27) # lsmod | egrep -i 'rng|tpm' tpm_crb20480 0 tpm_tis16384 0 tpm_tis_core 28672 1 tpm_tis tpm73728 3 tpm_tis,tpm_crb,tpm_tis_core rng_core 16384 3 ccp,tpm # uname -v #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-3 (2023-08-07) # lsmod | egrep -i 'rng|tpm' rng_core 20480 1 ccp And yet /dev/tpm0 exists in both kernels, but disappears when I physically remove the TPM, so the TPM is recognized to some degree even without those modules. Those four TPM-related modules are also present as files under /lib/modules in Linux 5.10, but absent in Linux 6.1. The corresponding source files still exist in the source tree. Have they been disabled in Debian 12? Have they been moved to some "extra modules" package that I haven't found? Or are they just not modules because they're statically built-in? > or identify the rng hardware a little better As I wrote in my first email, it seems to be an Infineon SLB 9665TT2.0. It says "SLB9665TT20" on the chip package. These characters are also written on the package. They mean nothing to me, but maybe they can be used to identify the hardware better: G1946KIV 51ZA947148IA1 (It's extremely difficult to tell I from 1 though.) > and look > for it in the kernel sources at > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random In that directory I don't see anything that looks relevant. The identifier "tpm-rng-0" comes from tpm_add_hwrng in drivers/char/tpm/tpm-chip.c, which is still there: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c?h=v6.1=830b3c68c1fb1e9176028d02ef86f3cf76aa2476#n517 Other functions in the same source file create /dev/tpm0, and it looks like the random number generator should get registered together with the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check the value of that option? Björn Persson pgperdoICnD28.pgp Description: OpenPGP digital signatur
Re: random number generator missing after upgrade
Jeffrey Walton wrote: > Maybe related to https://www.phoronix.com/news/Linux-Disables-RNG-AMD-fTPMs Not likely. That article is about a firmware TPM that comes with newer Ryzen processors. Older Ryzens supposedly don't have it. The processor in my APU2 is a GX-412TC, not a Ryzen at all, and my TPM is a discrete chip from Infineon. The change in question is supposed to disable the random number generator only if the TPM lists AMD as its manufacturer. Björn Persson pgpeOz3MAeGrY.pgp Description: OpenPGP digital signatur
random number generator missing after upgrade
Hello, I upgraded from Debian 11 to Debian 12, and my random number generator disappeared. When I boot vmlinuz-5.10.0-23-amd64, there are two hardware random number generators available: # cat /sys/class/misc/hw_random/rng_available ccp-1-rng tpm-rng-0 ccp-1-rng is nonfunctional because AMD's "Cryptographic Coprocessor" is too secretive to work with Coreboot, so I've been using tpm-rng-0. When I boot vmlinuz-6.1.0-11-amd64, there is no tpm-rng-0. Only the nonfunctional ccp-1-rng is available: # cat /sys/class/misc/hw_random/rng_available ccp-1-rng The hardware is an APU2 from PC Engines with this TPM board: https://www.pcengines.ch/tpm1a.htm The actual TPM seems to be SLB 9665TT2.0 from Infineon, (although the writing on the actual chip differs from Infineon's rendering): https://www.infineon.com/cms/en/product/security-smart-card-solutions/optiga-embedded-security-solutions/optiga-tpm/slb-9665tt2.0/ The TPM seems to still exist as /dev/tpm0, but its random number generator is somehow unavailable. Rebooting to Linux 5.10 makes tpm-rng-0 reappear and provide seemingly random numbers like it always did. That rules out a hardware problem. It's some difference between the two kernels, but so far I haven't found anything obvious in the Linux source code. Is there anything that can be done, or is support for this random number generator just gone from Linux 6.1? Björn Persson pgpgOVEgYOwhW.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
Stefan Monnier wrote: > Most of those ARM SBCs come with a µSD slot plus other things. > Even if you connect a SATA disk, you'll often need a µSD because some > of those SBCs don't have any on-board flash memory, so you need the µSD > to hold the U-Boot (which plays the role of the BIOS) without which the > board doesn't even know how to read from the SATA disk. I see. Being able to replace the memory that holds the bootloader makes perfect sense. That's even a feature I would pay extra for. Björn Persson pgpeO2iKh3u5U.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
Jonas Smedegaard wrote: > Quoting Björn Persson (2019-05-02 15:07:00) > > Jonas Smedegaard wrote: > > > Most but not all areas that Geode CPUs previously covered, nowadays > > > is covered by ARM SoCs. You may find this useful: > > > https://wiki.debian.org/CheapServerBoxHardware > > > > Something ARM-based might well be a candidate, yes. Thanks for the > > list, but its requirements are partially different from mine. For > > example a microSD slot isn't a hard requirement for me. > > Not sure why you emphasize MicroSD - it just happens to be the storage > type most common among cheap ARM boards. Maybe it's only because I'm not familiar with the ARM world. I think of memory cards as a removable medium that's used for copying files between devices – especially from a camera to a computer. I tend to assume that permanently mounted storage devices use SATA (unless requirements are so high that NVME or SAS is used). If there are quality microSD cards nowadays that are performant and reliable enough to replace a disk or SSD, then I suppose I could use that. When I see "uSD slot, easy accessible" in a bulleted list of what looks like requirements, then I get the impression that any device that lacks a microSD slot, or where it's not easy to access, would be excluded. I wouldn't reject an otherwise promising computer just because it has a SATA disk instead of a microSD card, and I don't mind using a screwdriver if I need to replace a hard disk. That's all I meant. Björn Persson pgpn0YQwT1ViJ.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
deloptes wrote: > I do not see in the log > assignment to the disk, so I suspect the hard drive is not assigned > properly and can not be accessed - are you booting from a card, or disk or > usb? What if you try to disable pata_amd? > > [6.114215] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xe000 irq > 14 > [6.156075] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xe008 irq > 15 > ... > ... > [6.407833] ata1.00: supports DRM functions and may not be fully > accessible > [6.449569] ata1.00: ATA-9: Samsung SSD 850 PRO 1TB, EXM02B6Q, max > UDMA/133 > [6.491306] ata1.00: 2000409264 sectors, multi 1: LBA48 NCQ (depth 0/32) > > and nothing like sda or hda. Yes, some kind of disk access problem seems likely, seeing that the disk activity light gets stuck on. This SATA SSD is the one and only storage device in the box, and the bios and Grub read it just fine, but maybe Linux somehow can't. Björn Persson pgpOyVFWO87QZ.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
I've been trying various kernel command line parameters that have been suggested in this thread. None of these made any noticeable difference: · acpi=off · systemd.restore_state=0 · init=/lib/sysvinit/init · init=/bin/sh I also found a parameter called initcall_debug that seemed like it might provide more data, but that didn't lead anywhere either. Even with init=/bin/sh I still see the string "starting version 232" – which is the version number of SystemD – and "uninitialized urandom read" messages that mention systemd-udevd and udevadm. Fortunately the presence or absence of "quiet" has an obvious effect. Otherwise I would have started to think that Grub ignored my changes to the command line. Unpacking and examining initrd.img-4.9.0-9-686 I find that /sbin/init is actually Busybox. So is /bin/sh, so that might explain why they both do the same thing. /lib/sysvinit/init doesn't exist in the initrd, but apparently Busybox gets started anyway. (Perhaps Linux falls back on the default if the requested init program doesn't exist?) It seems that I'll have to hack the initrd somehow if I am to get at a shell and poke around in the initrd environment. Booting from USB has been suggested several times. I'll do that if someone can tell me the magic incantation that makes Combios boot a USB device. I doubt it's possible. PXE booting is supposed to work. Maybe some day in a few weeks or months I'll find the time to set up a boot server. Björn Persson pgpNeGHHDane1.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
Jonas Smedegaard wrote: > Most but not all areas that Geode CPUs previously covered, nowadays is > covered by ARM SoCs. You may find this useful: > https://wiki.debian.org/CheapServerBoxHardware Something ARM-based might well be a candidate, yes. Thanks for the list, but its requirements are partially different from mine. For example a microSD slot isn't a hard requirement for me. Björn Persson pgpic3Us88oXE.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
Michael Lange wrote: > maybe you can try to use kernel packages from Antix, they seem to be > debian compatible and still have 486 versions > (see: https://mirror.23media.com/mx-packages/antix/stretch/pool/main/l/) Hmm, possibly an option to consider. At a glance I don't see a way to combine repositories to get only the kernel from Antix. Björn Persson pgpnaW3EVBrbX.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
bw wrote: > Before you dump it, I'd sure confirm the situation, document the flags and > file a bug against the release notes, so maybe that can get fixed in > buster release notes? I filed this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928340 Björn Persson pgpnminCguCUR.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
bw wrote: > p.s. In the past I always tested a live system before upgrading, or > installing a new release, even though it is not suggested in the release > notes about upgrading. IMHO, it is a good idea to always use a live > system for awhile and read some manpages on the machine. There's really > no practical way to cover every situation in the documentation. This is a small headless box. It has no CD drive or anything like that. There is one USB port, but finding out how to boot it from USB would be a major research project, if it's even possible. The BIOS is a rather minimal thing that can only be accessed over a DE-9 serial port. I was also running short on time. I got a message from Let's Encrypt that they were withdrawing the validation method I was using, forcing me to upgrade Certbot, and a sufficiently recent Certbot wasn't available for Debian 8. Other urgent problems had been taking up most of my time, and my certificates were about to expire. Therefore I decided that the quickest solution was to copy the entire SSD to a new one, installing the new SSD, and doing the upgrade to find out whether it would work. It did work well enough that I got the certificates renewed, so the immediate crisis is successfully averted. Now I have a slightly less urgent crisis instead. I can still roll back by putting the old SSD back and copying over the certificates and other data, but then I'll have to install and maintain an unpackaged Certbot, if possible, or find another ACME client that works, and I'll still have to move away from Debian 8 within 14 months. So if this processor is actually not supported anymore (contrary to the information that Jonas Smedegaard linked to), then it looks like I should get started on replacing the hardware, rather than putting a lot of work into temporary solutions. It's sad to have to throw away working hardware, but that's the way it is in the whole industry. Debian is at least better than many others in that regard. Björn Persson pgpDNTiNNbv6z.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
Björn Persson wrote: > Brian wrote: > > brian@futro:~$ uname -a > > Linux futro 4.9.0-7-686 #1 SMP Debian 4.9.110-3+deb9u1 (2018-08-03) i586 > > GNU/Linux > > That's an older Linux than I got. Perhaps I could try that package, if > I can get hold of it. I've installed linux-image-4.9.0-7-686. It hangs in the same way as the later versions. I don't know why it works for you and not for me. Björn Persson pgp5RvmYINmjn.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
deloptes wrote: > I have latest kernel custom build Built by you? Or does somebody publish custom kernels for Debian on Geode? > and I am on the geode mailing list. What mailing list? Björn Persson pgpeRWBfUGQIO.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
bw wrote: > You tested a live 686 image, or the installer? I followed these instructions: https://www.debian.org/releases/stretch/i386/release-notes/ch-upgrading.html Björn Persson pgpUGMBHO1h__.pgp Description: OpenPGP digital signatur
Re: Is Debian 9 supposed to work on a Geode?
Jonas Smedegaard wrote: > The officially supported CPUs - and how to check if yours is covered: > https://www.debian.org/releases/stable/i386/release-notes/ch-information.da.html#i386-is-now-almost-i686 According to that test my processor should be OK. It has all of those flags. Brian wrote: > If it helps, 'cat /proc/cpuinfo" for my running Fujitsu Siemens A250 is: > > processor : 0 > vendor_id : AuthenticAMD > cpu family : 5 > model : 10 > model name : Geode(TM) Integrated Processor by AMD PCS > stepping: 2 > cpu MHz : 498.046 > cache size : 128 KB > physical id : 0 > siblings: 1 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fdiv_bug: no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext > 3dnowext 3dnow 3dnowprefetch vmmcall > bugs: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass > bogomips: 996.09 > clflush size: 32 > cache_alignment : 32 > address sizes : 32 bits physical, 32 bits virtual > power management: Mine is: processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 microcode : 0x8b cpu MHz : 499.891 cache size : 128 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow vmmcall bogomips: 999.78 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: The family, model and stepping numbers are the same. The flags are the same except for 3dnowprefetch. I guess different versions of Linux might explain some differences. So far I've seen two replies saying it should work and two saying it should not, so I'm rather confused at the moment. > brian@futro:~$ uname -a > Linux futro 4.9.0-7-686 #1 SMP Debian 4.9.110-3+deb9u1 (2018-08-03) i586 > GNU/Linux That's an older Linux than I got. Perhaps I could try that package, if I can get hold of it. Björn Persson pgpQ7fnCpjycc.pgp Description: OpenPGP digital signatur
Is Debian 9 supposed to work on a Geode?
Hello! I have a small server with a Geode processor – Geode LX 500 MHz according to the BIOS boot screen – which I needed to upgrade from Debian 8 to Debian 9. I know that Debian has dropped support for i586, but I haven't been able to find a definitive answer to how that affects Geodes. What little I could find on the Web seemed to suggest that Geodes are mostly like i686, which is supposed to still be supported by Debian 9, so I decided to try it, took a backup, and took the plunge. It turns out that the kernel from Debian 9 won't boot. Both Linux 4.9.0-8-686 and 4.9.0-9-686 appear to hang early in the boot process. Everything else seems to work, so right now I'm running Debian 9 on Linux 3.16.0-8-586 from Debian 8. This works for now, but it's obviously not a long-term solution. So my question is: Is the Geode LX among the dropped processors, or is the hang a bug that should be fixed? Björn Persson pgp7xK4ilcgS_.pgp Description: OpenPGP digital signatur
Re: Om att svara till listan
tisdagen den 18 mars 2003 12:20 skrev Mattias Östergren: Rätt adress får programmet från någon av dessa headers, antar jag: X-Mailing-List: debian-user-swedish@lists.debian.org archive/latest/3806 X-Loop: debian-user-swedish@lists.debian.org List-Post: mailto:debian-user-swedish@lists.debian.org Ser man på! Jag ser att List-Post är definierat i RFC 2369, som har status av proposed standard. Björn Persson
Re: Om att svara till listan
tisdagen den 18 mars 2003 19:14 skrev Qerub: För mig räcker det med att trycka på L, det är jag säker på för det jag gjorde jag precis. Men om mutt hade jag väldigt fel, vet inte var jag hade fått det där ifrån. Hmm, jag ser att du har en nyare Kmail än jag, så det kan ju vara en funktion som har tillkommit. Björn Persson
Verifiering av paket
Jag skulle gärna vilja få litet klarhet i frågan om signaturer på debianpaketen. Är jag alltså hänvisad till att ladda ned paketen manuellt och kolla MD5-summorna om jag vill vara hyfsat säker på att de är äkta, eller kan det automatiseras? CD-avbilderna är en sak, dem kan man ju kolla en gång för alla, men jag kommer också att behöva vissa paket från Sarge - jag måste till exempel ha Xfree86 4.2 till mitt grafikkort - och så vill jag naturligtvis installera säkerhetsuppdateringarna. Och förresten: Sedan jag skrev ovanstående har jag börjat misstänka att det inte är någon idé att konfigurera Debconf-verify. Debsig-verify menade jag naturligtvis. Björn Persson
Re: Verifiering av paket misslyckas vid installation.
Hmm, här kan man visst inte bara trycka på Reply och vänta sig att svaret skickas till listan. söndagen den 16 mars 2003 15:20 skrev Björn Persson: söndagen den 16 mars 2003 00:53 skrev Lars Hallberg: Har du debsig-verify installerad? Hur konfigurerade du policyn i så fall? Prova att avinstallera debsig-verify, eller kör dpkg-reconfigure debsig-verify Ja, Debsig-verify var installerat. Jag tycker mig minnas att det redan var valt när installationsprogrammet först startade Dselect åt mig, men jag kan minnas fel. Jag fick aldrig någon fråga om att konfigurera någon policy. Katalogerna /etc/debsig/policies och /usr/share/debsig/keyrings var tomma, vilket torde förklara att verifieringen misslyckades. dpkg-reconfigure debsig-verify tycktes inte göra något särskilt, men efter att ha avinstallerat Debsig-verify kan jag nu installera andra paket. Tack för hjälpen! Nu måste jag bara lista ut hur jag ska få Debsig-verify korrekt konfigurerat, så att jag kan verifiera paket som jag installerar från Nätet. Björn Persson Sedan jag skrev ovanstående har jag börjat misstänka att det inte är någon idé att konfigurera Debconf-verify. Paketen tycks inte vara signerade. Inte ens i en säkerhetsuppdatering från security.debian.org hittade jag någon signatur. Ska det vara så, eller har jag missat något igen? Björn Persson
Om att svara till listan
måndagen den 17 mars 2003 20:29 skrev Qerub: I alla fall, både mutt och kmail kan svara till mailing list:en med en knapptryckning på L. Nja, i Kmail måste jag först skapa en korg, konstruera ett filter som skickar breven till korgen samt tala om för Kmail att korgen är avsedd för en epostlista och vilken adress listan har. *Sedan* kan jag svara till listan med ett tryck på L. Korgen och filtret skulle väl de flesta skapa ändå om de hade för avsikt att bli långvariga på listan, men nog vore det enklare om Kmail kunde se i brevet att det är från en lista. Björn Persson
Verifiering av paket misslyckas vid installation.
Hej Debianvänner! Jag försöker installera Woody från en CD gjord av debian-30r1-i386-binary-1_NONUS.iso. Installationen av bassystemet verkade gå bra, men efter omstarten, när jag hade valt paket att installera, gick något fel. Somliga paket verkade installeras korrekt, eftersom de visade meddelanden som jag fick svara OK på. Sedan kom det upp en lista på ett tjugotal paket som hade misslyckats, och jag erbjöds att köra Tasksel och Dselect igen - och där sitter jag fast. Jag avslutade installationsprogrammet, startade om och körde Dselect manuellt, och fick precis samma problem. Om jag väljer bort paketen som misslyckas så fylls listan bara på med andra misslyckade paket. Ovanför listan över misslyckade paket kan jag se felmeddelandet Verification on package si-och-så.deb failed!. Jag tror att samma sak händer med alla paketen, men texten rasar förbi för fort för att jag ska hinna se. Jag har kollat att CDn är felfri. Skivan är identisk med avbildsfilen, MD5-summan av avbilden är korrekt och Philip Hands signatur på filen med MD5-summor är korrekt. Vad kan jag ha missat? Björn Persson
