Re: F24 System Wide Change: Default Local DNS Resolver
On Mon, Dec 07, 2015 at 12:23:34PM +0100, Lennart Poettering wrote: > On Mon, 07.12.15 10:48, Tomas Hozza (tho...@redhat.com) wrote: > > > On 04.12.2015 15:57, Lennart Poettering wrote: > > > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote: > > As you've said, this is basically an attack and hijacking of someone's > > else domain name space. It is not correct and it is not expected that > > this will work with DNSSEC. > > Humm, I find that way too cavalier... I am pretty sure this is a total > deal breaker for your feature. You cannot just break everybody's > network and not consider that a problem that *you* have to think about > rather than just ignoring it completely. not everyones network - I allways use the IP to access routers. It should be a feature of unbound to find the router and offer a stable DNS pseudo-entry for that. Richard -- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox addon signing
On Wed, Feb 11, 2015 at 10:30:11PM -0600, Michael Cronenworth wrote: > I'm sure those that need to know, know, but for those that haven't heard[1] > Mozilla's official Firefox build will enforce addons to contain a Mozilla > signature without any runtime option to disable the check. > > Initially this prevents Fedora packaged addons since they are unsigned. The > Mozilla signing process takes time and can't be part of a package building > process. > > Is Fedora going to get authorization to build Firefox with a runtime disable > option? I have created https://bugzilla.redhat.com/show_bug.cgi?id=1257566 Richard -- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox addon signing
On Thu, Aug 27, 2015 at 02:28:48AM +0200, Reindl Harald wrote: > > Am 27.08.2015 um 02:21 schrieb Solomon Peachy: > >On Wed, Aug 26, 2015 at 05:53:36PM +0200, drago01 wrote: > >>A better solution would be to add a mechanism that allows you to use > >>your own signing keys. > >>That way you have both 1) install self built extensions and 2) the > >>added security. > > > >..and (3) a way for malware to install its own key, rendering (2) moot > > that would imply that malware running as root and then you have already lost > the whole game - pretty sure nobody meant "your own signing keys" writeable > by the user firefox is running I suspect even malware with user rights will be able to effectively manipulate the firefox binary using LD_PRELOAD or many other methods. Having a working sandbox implementation would improve security much better. Richard -- Name and OpenPGP keys available from pgp key servers pgpyMRCSHlvZV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox addon signing
On Wed, Aug 26, 2015 at 05:53:36PM +0200, drago01 wrote: > On Wed, Aug 26, 2015 at 3:13 PM, Richard Z wrote: > > On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote: > >> Their FAQ is constantly updated: > >> > >> https://wiki.mozilla.org/Addons/Extension_Signing#FAQ > >> > >> I'm not sure if there is a valid practical reason to refuse submitting the > >> addons that we ship to their signing service or if it is against our > >> policies; at least mozilla-https-everywhere has been signed. > > > > that would work for Fedora - if it can be guaranteed that they sign new > > versions quickly. Immagine if one of our plugins had a security hole and > > mozilla would need days or weeks to sign it. As far as I can see Fedora > > specific extensions would have to be listed which means they would go > > through manual code review at mozilla. > > > >> Mozilla states that they will be offering an unbranded binary (en_US only) > >> for development and testing purposes. > > > > For me this appears the only possibility and I suspect there are more > > Fedora users like me maintaining their own Firefox extensions. > > > > So will we get a firefox-unbranded package? > > A better solution would be to add a mechanism that allows you to use > your own signing keys. which would be possible only with firefox-unbranded unless some wonder happens. > That way you have both 1) install self built extensions and 2) the > added security. might be a security gain for some people but not for me. Richard -- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox addon signing
On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote: > Their FAQ is constantly updated: > > https://wiki.mozilla.org/Addons/Extension_Signing#FAQ > > I'm not sure if there is a valid practical reason to refuse submitting the > addons that we ship to their signing service or if it is against our > policies; at least mozilla-https-everywhere has been signed. that would work for Fedora - if it can be guaranteed that they sign new versions quickly. Immagine if one of our plugins had a security hole and mozilla would need days or weeks to sign it. As far as I can see Fedora specific extensions would have to be listed which means they would go through manual code review at mozilla. > Mozilla states that they will be offering an unbranded binary (en_US only) > for development and testing purposes. For me this appears the only possibility and I suspect there are more Fedora users like me maintaining their own Firefox extensions. So will we get a firefox-unbranded package? Richard -- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox addon signing
On Thu, Feb 12, 2015 at 07:07:34PM +0100, Reindl Harald wrote: > > Am 12.02.2015 um 18:53 schrieb Simo Sorce: > >>Maybe it is only about preventing people from bundling the official > >>Firefox version with dodgy add-ons. Not downright malware, but things > >>users may not actually want without realizing it. The signature > >>checking means that those who prepare the downloads can no longer use > >>the unmodified upstream binary. Which in turn might force them not to > >>use Mozilla brands. > >> > >>Maybe this is a bit far-fetched, but after hours of staring at other > >>people's code today, it seems pretty reasonable to me. > >> > >>But what do add-on developers do? Surely there is a way to disable this > >>somehow? > > > >Mozilla stated they will have to use the Developer Version (Aurora was > >the name ?) or the nightlies ... > > than Fedora needs to switch to the developer version if that *really* can't > be disabled via about:config - that is a unacceptable restriction until > hmtlvalidator, livehttpheaders and friends are available sigend via the > mozilla page any news on that on our side? From firefox-devel I gather that the "feature" will land exactly as anounced. There will be no configurable option for the user or sysadmin to allow loading of plugins not signed by mozilla - be it Fedora signed plugins or my personal bunch of homebrown locally built plugins. So I think Fedora could provide 2 Firefox packages: * firefox-official with all restrictions * unbranded-firefoxlike-browser which is almost identical but without said restrictions Richard -- Name and OpenPGP keys available from pgp key servers pgp08yJMS7xHD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Validity of i686 as a release blocker
On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote: > In February[2] we sent out an email highlighting that the kernel team > was not going to treat i686 bugs as a priority. Since that time, we > have held true to our word and have not focused on fixing i686 bugs at > all. It seems that the wider community is also treating i686 > similarly. The kernel bug that was made automatic blocker because of > existing criteria was present in Fedora since the 4.1-rc6 kernel, > which was released May 31. It has been in every boot.iso created > since that date. Not a single person reported this issue until last > week. That is a timespan of two months. > > The kernel team has autotesting for i686 kernels, but the environment > there does not utilize boot.iso so it did not detect this. The QA > team has automated testing for some of this, but nothing for the i686 > architecture at all. It is not a priority there either. I regularly use i686 and have not done a fresh install since years so would not detect this. Maybe fresh installs aren't such a deal for i686 users and the apparent stability is the reason why it gets less testing. The hardware is not changing so if fresh bugs appear there is a good chance that something else than just i686 is broken? Appreciate all your efforts and would miss i686. Not a top priority but maybe the memory footprint has some advantages on USB live images? Richard -- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21: rngd read errors in syslog after recent update
Hi, seeing plenty of said messages in syslog and no clue where they come from: Jun 26 11:27:18 HOST netcf-transaction.sh: Running start: No pending transaction to rollback Jun 26 11:27:18 HOST rngd: read error Jun 26 11:27:18 HOST rngd: read error Jun 26 11:27:18 HOST rngd: read error Jun 26 11:27:18 HOST rngd: read error Jun 26 11:27:18 HOST rngd: read error Jun 26 11:27:18 HOST rngd: read error Jun 26 11:27:18 HOST rngd: read error Comes during boot, preceeded by lm_sensors,avahismartd. Any idea what to look at? No visible malfunction. Richard -- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: plowshare is not shipped with modules anymore
On Sun, Apr 26, 2015 at 01:14:03PM +0300, Pavel Alexeev wrote: > 17.04.2015 07:41, Ralf Corsepius пишет: > > On 04/17/2015 01:10 AM, Pavel Alexeev wrote: > >> Hi > >> > >> 14.04.2015 05:20, Ralf Corsepius пишет: > >>> On 04/14/2015 03:01 AM, Elder Marco wrote: > >>> > Ralf, plowshare is a command-line downloader/uploader for some of the > most popular file-sharing websites. Each module (written in bash) > corresponds to a different sharing site. The modules are > downloaded via > plowmod, from a oficial repository provided by upstream. > >>> Well, as I said before, I do not like packages, which are doing so. > >>> > >>> I consider them to be a security and data privacy risk, but I am not > >>> in a position to change upstreams nor users. > >>> > >>> My advise to users: Don't use such packages if you are concerned about > >>> your data and your installations' security. > >>> > >> If package provide some basic modules and also utilities for user to > >> manage update "channels" or repo in clean way, why not? > > Why would you trust such "update channels" and the content they provide? > > > > Who tells me their site is trustworthy and not run or having been > > taken over by a secret service, the Mafia or other criminals? > > > >> As was mentioned > >> early many software do the same. > > In Fedora? None that I am aware of, except of Mozilla, whose > > plugins/addons basically suffer from the same issue. Nothing but > > Mozilla itself prevents you from installing the "Nigerian Mafia" or > > the "NSA-Trojan" add-ons. > > > >> Although we do not ship any external > >> yum repos in rpm there clear way for users how to add others. > > Correct. The rationale not to allow non-fedora repos in Fedora is > > basically the same. > What mean not to allow? You do not understand me. Not ship by default in > distribution is not mean not allow. Repo-format well defined, > yum-config-manager allow add repos. > > > >> And it may > >> be much more security breach. > > Well, instead of relying on Fedora shipping a fixed set of scripts > > (which should have been reviewed and tested by the package maintainer > > and protected from forgery with rpm), they want users to download > > install arbitrary scripts from their site. > Do you really think maintainer of any package may review all upstream > commits to guarantee anything about upstream software state, quality or > mallware presents? Off course we all want and try to do not bring bad > things in Fedora, but really it mostly on upstream developer side > happened what happened. the maintainer will not catch everything, but it is already a huge win if everyone gets the same code from Fedora. Makes it much harder to play MITM against individual users and if something happens and several users have been shipped the same malicious code there is a much better chance to investigate the damage properly if the code was packaged than if the code was downloaded on the fly and everyone has his personalised/fuzzed malware. > As pip, rybygems, maven do not forbidden download and install external > dependencies I hope plowmod also may do that. would not want to forbid plowmod to install external dependencies but it should be avoided as far as possible, certainly not the default behaviour. As of maven, I am also uncomfortable that it downloads gigabytes of stuff from somehwere on the internet. Maximum obfuscation, minimum utility while introducing security risks for no gain. Richard --- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: plowshare is not shipped with modules anymore
On Mon, Apr 13, 2015 at 10:01:28PM -0300, Elder Marco wrote: > > Jason, thanks! I could package the modules. But this is not a good ideia as > explained above. The package will be quickly outdated. Perharps, before I > mark it as stable. However, if necessary, I will submit a review request to > a new package, that will contain the modules. even at the risk that the modules will be frequently outdated I would prefer having them packaged by Fedora. Already the idea of writing bash scripts which attempt to deal with web-content sounds like a security nightmare. Richard --- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
On Mon, Mar 30, 2015 at 08:57:56AM +0200, Till Maas wrote: > There the problem is, that dracut runs a fsck check before deciding > whether to resume. This can result in a big file system corruption, > since the kernel had a different idea of the file system state after > resuming from hibernation that there really is. thanks for spotting that. I have seen the resulting fs corruption and was suspecting something like that but was unable to investigate the details. Richard --- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
mirror.root.lu causing consistent hangs?
Hi, yesterday and today this mirror caused yum to hang for indefinite periods of time (waited over two minutes), only c-c helps. Richard --- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: repo-mirrorlist quality control?
On Wed, Feb 25, 2015 at 10:22:08AM -0700, Kevin Fenzi wrote: > On Wed, 25 Feb 2015 17:47:47 +0100 > Ralf Corsepius wrote: > > > There will be such times, sure. > > Here (Germany), in recent times, they happen almost daily. My guess > > is the "fedora flavors", the launch of f22 and the mass-rebuild on > > rawhide are showing their nasty side. > > So, to be clear you see daily where 'yum update' gives you all mirrors > erroring out and you cannot get a update list? And 'yum clean all' > doesn't help? in my case those are only very rarely hard errors, yum tries one or a few more mirrors and continues so maybe not everyone notices. But the errors are very frequent recently, seems like for every package that is to be updated yum tries a list of known bad mirrors before getting it from some other mirror. In part I blame yum - when updating 50 packages in one transaction and a single mirror fails more than once it is silly to retry this very mirror over and over for all other packages. But something also seems wrong with the mirror configuration here. Richard --- Name and OpenPGP keys available from pgp key servers pgpPA59bzYoVq.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
repo-mirrorlist quality control?
Hi, when doing yum update in the last few weeks I am seeing thousands of errors like (1/2): _local/primary_db| 3.4 MB 00:00 updates/21/i386/primary_db FAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/1f20884a6cce1ba8e28bb19e6dd364fe787906c1f0504c0d06e0fb1be8ab07ac-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. updates/21/i386/primary_db FAILED http://mirror.fraunhofer.de/dl.fedoraproject.org/fedora/linux/updates/21/i386/repodata/1f20884a6cce1ba8e28bb19e6dd364fe787906c1f0504c0d06e0fb1be8ab07ac-primary.sqlite.bz2: [Errno 14] curl#18 - "transfer closed with 1521891 bytes remaining to read" Trying other mirror. (2/2): updates/21/i386/primary_db | 4.5 MB 03:26 updates/21/i386/updateinfo FAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/343502d43eec1d45e0f951d2c2d3373a146515d175e61c1609b44391f93cf08a-updateinfo.xml.gz: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. updates/21/i386/pkgtagsFAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/6803dec7b564b291cead9d2b720a47bb73da52577e7f25e5b9df41582455f7a1-pkgtags.sqlite.gz: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. (1/2): updates/21/i386/updateinfo | 644 kB 01:28 (2/2): updates/21/i386/pkgtags | 1.4 MB 03:11 and http://mirror.netcologne.de/fedora/linux/updates/21/i386/drpms/autocorr-en-4.3.5.2-11.fc21_4.3.6.2-3.fc21.noarch.drpm: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. While very rarely some other mirrors have problems, netcologne seems to be failing systematically for me. Is it just me? Is there some place to report? Richard --- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: So everything in Rawhide must be compiled with -fPIC?
On Fri, Feb 20, 2015 at 07:28:50PM +, Peter Robinson wrote: > On Fri, Feb 20, 2015 at 6:55 PM, Till Maas wrote: > > On Fri, Feb 20, 2015 at 05:21:59PM +, Peter Robinson wrote: > >> >> I've never argumented against the goal that web browser or all network > >> >> aware > >> >> services should be PIEs, after all, why would we (Ulrich Drepper and > >> >> myself) > >> >> add the PIE support into the toolchain otherwise? > >> >> I'm just not convinced most of the unpriviledged programs should be > >> >> PIEs. > >> > > >> > Thanks to e.g. e-mail about any program can be made to run untrusted > >> > data, e.g. PDF readers, office suites, image viewers, if you open an > >> > attachment of the respective type. Therefore it makes a sane default > >> > IMHO. It is also something to attract users that care about security > >> > very much to Fedora. > >> > >> So your saying here that this is miraculously going to stop people > >> from running random binaries that are being emailed to them? Or is > >> just going stop people from running random non PIC/PIE binaries? I > >> don't buy that this is a miracle fix to that problem. How then does it > >> affect other third party binaries not compiled with PIC/PIE that > >> people might wish to run? > > > > No, am am saying I can open PDF documents knowing that I did what I > > could to be secure when open it etc. Also I know that if recommend > > people Fedora and give basic guidelines, that they are as good protected > > as possible. > > How is a PDF with a binary payload any different? Sounds like we need > to be running pdf readers in a selinux container? absolutely. All PDF, office, web browsers and similar should be pre-configured to use sandboxing technology. The plain selinux sandbox also needs some work - right now you can even read /etc/passwd* out of normal sandboxes! https://bugzilla.redhat.com/show_bug.cgi?id=1165424 Richard --- Name and OpenPGP keys available from pgp key servers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 hiberantion/resume eating filesystems
On Tue, Jan 13, 2015 at 01:28:56PM +0100, Richard Z wrote: > - tune2fs -C 1 dev is apparently ignored on all devices as pointed out on bugzilla that was my mistake, I have confused the options in the hurry. Richard --- Name and OpenPGP keys available from pgp key servers pgpu_SRmf_pZY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 hiberantion/resume eating filesystems
Hi, have very recently upgraded from F19 to F21 and notice scary log entires after hibernation/resume. Watch your logs! The hardware (in combination with F19) was rock solid all the time and is fairly boring. I am still running 32 bit x86. No sign of any problems when not hibernating. I have completely encrypted root/home/swap. Is this a kernel problem or is there any chance that during boot the filesystem was written before the resume was intiated? Also - rather disturbing - despite potentially serious errors in the filesystem - filesystem check is not forced after reboot - tune2fs -C 1 dev is apparently ignored on all devices https://bugzilla.redhat.com/show_bug.cgi?id=1181322 Can not give all messages here - come of the more serious apparently have been lost possibly due to fs corruption. Those that were lost were of the kind " There's a risk of filesystem corruption in case of system crash." Those that were preserved are of the kind Jan 11 18:10:09 rz kernel: [ 4486.613583] EXT4-fs error (device dm-5): ext4_mb_generate_buddy:757: group 258, block bitmap and bg descriptor inconsistent: 4880 vs 4724 free clusters Jan 11 18:10:09 rz kernel: [ 4486.648386] EXT4-fs error (device dm-5): ext4_free_inode:340: comm tcptrack: bit already cleared for inode 2127171 Jan 11 18:10:09 rz kernel: EXT4-fs error (device dm-5): ext4_mb_generate_buddy:757: group 258, block bitmap and bg descriptor inconsistent: 4880 vs 4724 free clusters Jan 11 18:10:12 rz kernel: EXT4-fs error (device dm-5): ext4_free_inode:340: comm tcptrack: bit already cleared for inode 2127171 Jan 11 18:10:20 rz kernel: [ 4497.917092] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656088: doubly allocated? Jan 11 18:10:20 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656088: doubly allocated? Jan 11 18:10:25 rz kernel: [ 4502.692300] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656095: doubly allocated? Jan 11 18:10:25 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656095: doubly allocated? Jan 11 18:10:31 rz kernel: [ 4508.156434] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656626: doubly allocated? Jan 11 18:10:31 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656626: doubly allocated? Jan 11 18:11:41 rz kernel: [ 4579.069411] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656820: doubly allocated? Jan 11 18:11:41 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656820: doubly allocated? # lspci 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) 00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 01) 00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01) 00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01) 00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01) 00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01) 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01) 00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02) Richard --- Name and OpenPGP keys available from pgp key servers pgp6Kx4x_nSbE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
