docs-qa November 2013

docs-qa@lists.fedoraproject.org

1 participants
166 discussions

[Bug 892673] New: UEFI Secure Boot Guide: suggestions for edits
by Red Hat Bugzilla 27 Jun '14

27 Jun '14

Product: Fedora Documentation https://bugzilla.redhat.com/show_bug.cgi?id=892673 Bug ID: 892673 Summary: UEFI Secure Boot Guide: suggestions for edits Product: Fedora Documentation Version: devel Component: uefi-secure-boot-guide Severity: unspecified Priority: unspecified Reporter: fweimer(a)redhat.com Replace: "With the planned release of Windows 8, Microsoft has decided that all hardware that is marked "Windows 8 client ready" should" With: "Microsoft requires that client devices carrying the Windows 8 logo must" Replace: "This means that Fedora as it stands booted on such hardware will refuse to boot until the user disables secure boot in the firmware." With: "The UEFI boot loader on Fedora installation media and on the installed system are signed with the Microsoft key, to enable booting and installation on such systems." Remove the following paragraph, ending in "This plan has been approved by the Fedora Engineering Steering Committee as of 23-Jul-2012." After: "any operations from userland which cause userland-defined DMA" Insert: "disable support for hibernate/suspend-to-disk, and other features which would allow executing arbitrary code in kernel mode (even for the root user)." -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

[Bug 782916] New: value of security measures; no metric, no scope description
by Red Hat Bugzilla 27 Jun '14

27 Jun '14

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: value of security measures; no metric, no scope description https://bugzilla.redhat.com/show_bug.cgi?id=782916 Summary: value of security measures; no metric, no scope description Product: Fedora Documentation Version: devel Platform: Unspecified OS/Version: All Status: NEW Severity: unspecified Priority: unspecified Component: security-guide AssignedTo: eric(a)christensenplace.us ReportedBy: budden(a)nps.navy.mil QAContact: docs-qa(a)lists.fedoraproject.org CC: pkennedy(a)redhat.com, eric(a)christensenplace.us, security-guide-list(a)redhat.com, oglesbyzm(a)gmail.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Description of problem: The juncture between computer security and network security is inadequate -- too many seams which leaves too many man-in-middle attack opportunities. The most egregious omission in this (otherwise pretty good) document is treatment of SCOPE. This probably belongs in the vicinity of 1.3. Analysis first. Map each of the security solutions you have in the guide onto the ISO Reference Model: Layer 1/2 security measures (like WiFi security) protect frames. The scope of the security is limited to a single segment. No security beyond the router and no security within end systems. Layer 3 security protected datagrams (VPNs do this, IPSec ....). The scope is an enclave tunneled through an internetwork. The protection cannot extend beyond the VPN boxes, so data is wholly unprotected within end systems (and LAN if the VPN box is associated with the last router). Layer 4/5 security includes SSL (aka TLS). You have a how-to for securing an http server (good) but no admonitions regarding scope -- the security extends from the TCP socket in one end system to the TCP socket at the other end of the connection -- again no security inside the OS comes from SSL. All of the above security measures protect infrastructure. But they do not protect the data. Layer 6/7 security measures protect the data. Here the scope _can be_ truly end to end. S/MIME is a good example (so is ssh and XML sign/crypt) where the data passes over the internet and through the OS in protected form. Only in a fairly small space is the data unprotected. In Evolution, for example, only the parts of the UA that deal with composing, reading, ... mail are places where the authenticity and confidentiality of the data is possible. Most of the rest of the UA (including all the filing system deals with data that has been protected exactly the way it's been sent over the network. In the case of Evolution (UAs differ in implementation) secured data is stored in the file system exactly the way it was transmitted. Recommendations: 1) include a mapping similar to above so users have an idea what the scope of this or that security measure is. 2) emphasize those security measures that apply to applications (layer 6/7) as Fedora distribution evolves and matures. (What got me here this morning is the continuing frustration getting Evolution to properly play ball with DoD CAC cards ... works, but doesn't 'just work'). Version-Release number of selected component (if applicable): Security Guide 16.3 (doesn't have a date) How reproducible: The above analysis doesn't invent anything; it only organizes and sorts. Anyone can reproduce it. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 2

[Bug 1005452] New: Outdated information
by Red Hat Bugzilla 19 Jun '14

19 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1005452 Bug ID: 1005452 Summary: Outdated information Product: Fedora Documentation Version: devel Component: rpm-guide Severity: medium Assignee: bcotton+fedora(a)gmail.com Reporter: cickumqt(a)gmail.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: bcotton+fedora(a)gmail.com, pkovar(a)redhat.com, zach(a)oglesby.co Quoted from http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM…: The RPM bindings for Python are documented along with the C programming API. On a Red Hat Linux system, look in the file /usr/share/doc/rpm-devel-4.1/apidocs/html/group__python.html to see the start of the Python-specific documentation. Note that much of this online documentation covers the C functions that provide the Python bindings, not the Python API itself. But, if you examine the online information on objects listed as classes, such as rpmts, you can find the Python-specific documentation. Furthermore, if you look into the .c files that make up the Python bindings, you can find PyMethodDef structure tables. These tables provide useful glimpses into the Python API. To learn more about programming in Python, install the python-docs package. The python-docs package has a large set of online documentation for Python, including the official Python Tutorial. With Red Hat Linux, start at /usr/share/doc/python-docs-2.2.1/html/tut/tut.html. Cross Reference Other tutorials are available at http://diveintopython.org for the Dive Into Python tutorial for experienced programmers, and at http://py.vaults.ca/parnassus/apyllo.py/935043691.636055170 for the Vaults of Parnassus listing of tutorials. I think we need to update some words like RPM4.1, /usr/share/doc/python-docs-2.2.1 (F20 docdir changes) and Red Hat Linux .... -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

[Bug 977063] New: New NetworkManager features should be documented
by Red Hat Bugzilla 21 Mar '14

21 Mar '14

https://bugzilla.redhat.com/show_bug.cgi?id=977063 Bug ID: 977063 Summary: New NetworkManager features should be documented Product: Fedora Documentation Version: devel Component: system-administrator's-guide Severity: unspecified Priority: unspecified Assignee: jhradile(a)redhat.com Reporter: me(a)petetravis.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: jhradile(a)redhat.com NetworkManager now offers hotspot functionality, allowing users to easily share a non-wireless connection over a wireless interface. As of F19, NetworkManager allows the creation and usage of both bridge and bond virtual devices. These features should be documented in the System Administrator's guide. --Pete -- You are receiving this mail because: You are the QA Contact for the bug.

1 3

[Bug 998327] New: http://docs.fedoraproject.org/ doesn't work for the Romanian language (ro-RO)
by Red Hat Bugzilla 05 Feb '14

05 Feb '14

https://bugzilla.redhat.com/show_bug.cgi?id=998327 Bug ID: 998327 Summary: http://docs.fedoraproject.org/ doesn't work for the Romanian language (ro-RO) Product: Fedora Documentation Version: devel Component: docs-requests Severity: high Assignee: nobody(a)fedoraproject.org Reporter: cristian.ciupitu(a)yahoo.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: nobody(a)fedoraproject.org, sparks(a)redhat.com, stickster(a)gmail.com, zach(a)oglesby.co Document URL: http://docs.fedoraproject.org/ Section Number and Name: http://docs.fedoraproject.org/ Describe the issue: If I put Romanian ([ro-RO] and/or [ro]) at the top of preferred languages in firefox-23.0-1.fc19.x86_64, the web page doesn't work. The page is loaded then the browser seems to be redirected to the same page over and over. Suggestions for improvement: Additional information: Visiting http://docs.fedoraproject.org/en-US/index.html directly works fine. Visiting http://docs.fedoraproject.org/xx-XX/index.html (literaly) starts a loop. I don't necessarily want the website translated into Romanian, I just want it to work even if it's in English. -- You are receiving this mail because: You are the QA Contact for the bug.

1 9

[Bug 1001330] New: ARM as primary Architecture
by Red Hat Bugzilla 03 Feb '14

03 Feb '14

https://bugzilla.redhat.com/show_bug.cgi?id=1001330 Bug ID: 1001330 Summary: ARM as primary Architecture Product: Fedora Documentation Version: devel Component: docs-requests Keywords: Tracking Assignee: nobody(a)fedoraproject.org Reporter: me(a)petetravis.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: dennis(a)ausil.us, jreznik(a)redhat.com, nobody(a)fedoraproject.org, pbrobinson(a)gmail.com, sparks(a)redhat.com, stickster(a)gmail.com, zach(a)oglesby.co Depends On: 998560 Blocks: 1001329 +++ This bug was initially created as a clone of Bug #998560 +++ This is a tracking bug for Change: ARM as primary Architecture For more details, see: http://fedoraproject.org//wiki/Changes/ARM_as_Primary Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit). --- Additional comment from Dennis Gilmore on 2013-08-22 18:57:11 EDT --- we are building arm as primary, everything is on target right now. Discussion at https://lists.fedoraproject.org/pipermail/devel/2013-July/184962.html Please assess existing documentation for the impact of this Change. -- You are receiving this mail because: You are the QA Contact for the bug.

1 5

[Bug 1021599] New: ARM as primary Architecture
by Red Hat Bugzilla 03 Feb '14

03 Feb '14

https://bugzilla.redhat.com/show_bug.cgi?id=1021599 Bug ID: 1021599 Summary: ARM as primary Architecture Product: Fedora Documentation Version: devel Component: install-guide Keywords: Tracking Assignee: pbokoc(a)redhat.com Reporter: pbokoc(a)redhat.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: dennis(a)ausil.us, jreznik(a)redhat.com, pbokoc(a)redhat.com, pbrobinson(a)gmail.com, zach(a)oglesby.co Depends On: 998560 Blocks: 1001329, 1001330 +++ This bug was initially created as a clone of Bug #998560 +++ This is a tracking bug for Change: ARM as primary Architecture For more details, see: http://fedoraproject.org//wiki/Changes/ARM_as_Primary Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit). --- Additional comment from Dennis Gilmore on 2013-08-22 18:57:11 EDT --- we are building arm as primary, everything is on target right now. --- Additional comment from Jaroslav Reznik on 2013-10-11 04:46:20 EDT --- This message is a reminder that Fedora 20 Accepted Changes 100% Completed Deadline is on 2013-10-15 [1]. All Accepted Changes has to be code complete and ready to be validated in the Beta release (optionally by Fedora QA). Required bug state at this point is ON_QA. As for several System Wide Changes, Beta Change Deadline is a point of contingency plan, all incomplete Changes will be reported to FESCo for 2013-10-16 meeting. In case of any questions, don't hesitate to ask Wrangler (jreznik). [1] https://fedoraproject.org/wiki/Releases/20/Schedule --- Additional comment from Jaroslav Reznik on 2013-10-16 05:32:34 EDT --- As agreed by Change owner, moving to ON_QA as a completed Change. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=998560 [Bug 998560] ARM as primary Architecture https://bugzilla.redhat.com/show_bug.cgi?id=1001329 [Bug 1001329] ARM as primary Architecture https://bugzilla.redhat.com/show_bug.cgi?id=1001330 [Bug 1001330] ARM as primary Architecture -- You are receiving this mail because: You are the QA Contact for the bug.

1 2

[Bug 1008749] New: Add info to install-guide about deleting orphaned and obsolete packages after fedup upgrade
by Red Hat Bugzilla 01 Feb '14

01 Feb '14

https://bugzilla.redhat.com/show_bug.cgi?id=1008749 Bug ID: 1008749 Summary: Add info to install-guide about deleting orphaned and obsolete packages after fedup upgrade Product: Fedora Documentation Version: devel Component: install-guide Severity: low Assignee: pbokoc(a)redhat.com Reporter: timwa1(a)optusnet.com.au QA Contact: docs-qa(a)lists.fedoraproject.org CC: pbokoc(a)redhat.com, zach(a)oglesby.co Had a quick look and cannot find any info in docs about this problem. Add info to install-guide about deleting orphaned and obsolete packages after fedup upgrade. Until a garbage collection program or fedup etc updating this info is required so users can do it manually. Version-Release number of selected component (if applicable): Fedora-install docs F19+ How reproducible: Refer Bug id 978037 which shows that an F17 obsoleted package found in F19 current release after upgrade with fedup from F17. Steps to Reproduce: 1. install F18 2. fedup upgrade to F19 3. Run the commands in Bug id 978037 Comment 6 to see obsoleted or orphaned packages. Actual results: yum local repo still has obsolete and orphaned packages after fedup upgrade Expected results: Until a garbage collection program is completed or fedup is updated please add this to install documenation. Additional info: -- You are receiving this mail because: You are the QA Contact for the bug.

1 2

[Bug 1008224] New: SDDM as the default KDE display manager instead of KDM
by Red Hat Bugzilla 26 Jan '14

26 Jan '14

https://bugzilla.redhat.com/show_bug.cgi?id=1008224 Bug ID: 1008224 Summary: SDDM as the default KDE display manager instead of KDM Product: Fedora Documentation Version: devel Component: docs-requests Keywords: Tracking Assignee: nobody(a)fedoraproject.org Reporter: me(a)petetravis.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: dvratil(a)redhat.com, gbcox(a)bzb.us, jgrulich(a)redhat.com, jreznik(a)redhat.com, kevin.kofler(a)chello.at, ltinkl(a)redhat.com, massi.ergosum(a)gmail.com, mbriza(a)redhat.com, nobody(a)fedoraproject.org, rdieter(a)math.unl.edu, rtguille(a)gmail.com, sparks(a)redhat.com, stickster(a)gmail.com, than(a)redhat.com, zach(a)oglesby.co Depends On: 998542, 1007065, 1007067, 997187, 998978, 1003619 +++ This bug was initially created as a clone of Bug #998542 +++ This is a tracking bug for Change: SDDM as the default KDE display manager instead of KDM For more details, see: http://fedoraproject.org//wiki/Changes/SDDMinsteadOfKDM Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. --- Additional comment from Martin Bříza on 2013-08-20 08:28:40 EDT --- So far only installable from the repositories, will set it as the default as soon as possible. Test with the steps described in http://fedoraproject.org//wiki/Changes/SDDMinsteadOfKDM#How_To_Test . --- Additional comment from Martin Bříza on 2013-08-27 07:39:46 EDT --- SDDM is now installed as a part of @kde-desktop. There aren't any live images of the spin yet but it's testable by adding the group (with --skip-broken because of broken deps in hugin) and graphics adapter drivers to the minimal install. ------------------------------------------------ Discussion at https://lists.fedoraproject.org/pipermail/devel/2013-July/185118.html Please assess existing documentation for the impact of this Change. -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

[Bug 1001338] New: Migrate to Bluez 5
by Red Hat Bugzilla 26 Jan '14

26 Jan '14

https://bugzilla.redhat.com/show_bug.cgi?id=1001338 Bug ID: 1001338 Summary: Migrate to Bluez 5 Product: Fedora Documentation Version: devel Component: release-notes Keywords: Tracking Assignee: relnotes(a)fedoraproject.org Reporter: me(a)petetravis.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: bnocera(a)redhat.com, jreznik(a)redhat.com, kalevlember(a)gmail.com, relnotes(a)fedoraproject.org, wb8rcr(a)arrl.net, zach(a)oglesby.co Depends On: 998563 +++ This bug was initially created as a clone of Bug #998563 +++ This is a tracking bug for Change: Migrate to Bluez 5 For more details, see: http://fedoraproject.org//wiki/Changes/Bluez5 BlueZ is the Linux Bluetooth stack for managing wireless Bluetooth devices. In Fedora 20, we are going to switch from BlueZ version 4 to version 5. Discussion at https://lists.fedoraproject.org/pipermail/devel-announce/2013-August/001227… Please create entries for this Change in the Release Notes. -- You are receiving this mail because: You are the QA Contact for the bug.

1 4

← Newer
1
...
10
11
12
13
14
15
16
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

docs-qa November 2013