Static Analysis: some UI ideas
by David Malcolm
I've been experimenting with some UI ideas for reporting static analysis
results: I've linked to two different UI reports below.
My hope is that we'll have a server in the Fedora infrastructure for
browsing results, marking things as false positives etc.
However, for the purposes of simplicity during experimentation I'm
simply building static HTML reports.
My #1 requirement when I'm viewing static analysis results is that I
want to *see the code* with the report, so I've attempted to simply show
the code with warnings shown inline.
Note also that when we have a server we can do all kinds of
auto-filtering behaviors so that e.g. package maintainers only see
warnings from tests that have decent signal:noise ratio (perhaps with
other warnings greyed out, or similar).
Results of an srpm build
========================
The first experimental report can be seen here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreut...
It shows warnings from 4 different static analyzers when rebuilding a
particular srpm (policycoreutils-2.1.13-27.2.fc17). There's a summary
table at the top of the report showing for each source files in the
build which analyzers found reports (those that found any are
highlighted in red). Each row has a <a> linking you to a report on each
source file. Those source files that have issues have a table showing
the issues, with links to them. The issue are shown inline within the
syntax-colored source files.
Ideally there'd by support for using "n" and "p" to move to
next/previous error (with a little javascript), but for now I've been
using "back" in the browser to navigate through the tables.
An example of an error shown inline:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreut...
shows a true error in seunshare.c found by cppcheck ("foo =
realloc(foo, , )" is always a mistake, since if realloc fails you get
NULL back, but still have responsibility for freeing the old foo).
Comparison report
=================
The second experimental report can be seen here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-04/comparison-o...
It shows a comparison of the results of two different builds of a
package (python-ethtool), again running multiple analyzers.
(specifically, a comparison between 0.7 and an snapshot of upstream
git).
It's similar to the first report, but instead of showing one file at a
time, it shows a side-by-side diff of old vs new file.
Any issues found in old or new source code are shown inline, so you can
see issues that are fixed, issues that are newly introduced, and issues
that are present in both old and new code.
Both reports could use some javascript to let you use "n" and "p" to go
to next/previous errors. Also my CSS is ugly.
Any javascript/css experts out there who can help with those areas?
(FWIW, the code that generates these are in:
https://github.com/fedora-static-analysis/mock-with-analysis/tree/master/...
specifically make-simple-report.py and make-comparative-report.py;
they're reading the output from mock-with-analysis)
Dave
11 years, 2 months
Proposed F19 Feature: Virtio RNG
by Jaroslav Reznik
= Features/Virtio RNG =
https://fedoraproject.org/wiki/Features/Virtio_RNG
Feature owner(s): Cole Robinson <crobinso(a)redhat.com>, Amit Shah
<amit.shah(a)redhat.com>
Provide a paravirtual random number generator to virtual machines, to prevent
entropy starvation in guests.
== Detailed description ==
The linux kernel collects entropy from various non-deterministic hardware
events, like mouse and keyboard input, and network traffic. This entropy is then
exposed through /dev/random, commonly used by cryptographic applications that
need true randomness to maintain security. However if more entropy is being
consumed than is being produced, we have entropy starvation: reading from
/dev/random will block, which can cause a denial of service. A common example
here is use of /dev/random by SSL in various services.
VirtIO RNG (random number generator) is a paravirtualized device that is
exposed as a hardware RNG device to the guest. Virtio RNG just appears as a
regular hardware RNG to the guest, which the kernel reads from to fill its
entropy pool. This effectively allows a host to inject entropy into a guest via
several means: The default mode uses the host's /dev/random, but a physical HW
RNG device or EGD (Entropy Gathering Daemon) source can also be used.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
udisks in rawhide
by Tomas Bzatek
FYI, the old-generation udisks package has been made orphan in rawhide,
nothing should be really using it nowadays. There's udisks2 (with
incompatible API) as a supported method for handling storage.
Is anybody still using udisks, the first generation? I see a few from
quick repoquery check. Maintainers please check if it's possible to
use/port to udisks2 instead.
# repoquery --whatrequires udisks
bashmount-0:1.6.2-4.fc18.noarch
emelfm2-0:0.8.2-1.fc19.x86_64
exaile-0:3.3.1-1.fc19.noarch
liveusb-creator-0:3.11.7-2.fc18.noarch
wmudmount-0:1.13-4.fc19.x86_64
yumex-0:3.0.10-1.fc19.noarch
(please keep me on Cc: when replying)
Thanks,
--
Tomas Bzatek
11 years, 2 months
Proposed F19 Feature: Trusted Network Connect (TNC)
by Jaroslav Reznik
= Features/Trusted Network Connect (TNC) =
https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29
Feature owner(s): Avesh Agarwal <avagarwa(a)redhat.com>
This feature provides Trusted Network Connect(TNC) framework that can be used
to assess and verify clients' posture (or integrity measurements or
configuration) and its compliance to a predefined policy with existing network
access control (NAC) solutions.
== Detailed description ==
Traditionally network access control (NAC) has lacked the ability in its
decision making to asses endpoint's security posture and its compliance to
enterprise policies. This lack of assessment may leave an enterprise's network
vulnerable to malicious attacks. Trusted Computing Group (TCG) (and IETF too)
has defined an open architecture called Trusted network connect (TNC) (IETF's
Network Endpoint Assessment (NEA)) to fill this gap. TNC, as part of its
architectural components, includes integrity measurement collectors (IMCs) and
TNC client at endpoint and integrity measurement verifiers (IMVs) and TNC
server at enterprise network side communicating over NAC solutions such as EAP
with 802.1X to evaluate and verify the security posture of the endpoint
against the enterprise policies before allowing network access. For this, TCG
has released transport (IF-T), session (IF-TNCCS) and messaging (IF-M)
standards which are open and interoperable. TNC architecture by virtue of it's
IF-M protocol can leverage NIST's SCAP's (OpenSCAP) automated security aspects
for measurement collection, verification and remediation. In addition, TCG has
defined IF-PTS and PTS protocol specifications to integrate platform trust
services (PTS) with TNC for TPM based attestation of integrity measurements.
PTS protocol defines messaging payloads to be used over IF-M protocol.
This feature includes the aforementioned functionalities and aims to provide
an end-to-end network based client assessment, verification and remediation.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Fedora ARM Weekly Status Meeting 2013-02-06
by Paul Whalen
Good day all,
This weeks Fedora ARM status meeting will take place today (Wednesday Feb 06th) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 9pm
BST: 9pm
CST: 10pm
Current items on the agenda:
0) Status of ACTION items from our previous meeting
1) Problem packages
2) Wiki Gardening - removing outdated content
3) Mass Rebuild - scheduling for ARM
4) Your topic here!
If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting.
Paul
11 years, 2 months
Proposed F19 Feature: QXL/Spice KMS Driver
by Jaroslav Reznik
= Features/QXLKMSSupport =
https://fedoraproject.org/wiki/Features/QXLKMSSupport
Feature owner(s): Alon Levy <alevy(a)redhat.com>
Currently the QXL driver is X.org only, a KMS driver is required to move
forward with projects like spice 3D, and also to allow more features to be
show in virt environments like plymouth.
== Detailed description ==
The current spice GPU driver for Linux guests is an X.org only driver. A
kernel modesetting driver needs to be developed along with a new X.org driver
that runs on top of it. Additionally the kernel driver will allow it to work
with the modesetting DDX driver. The new ioctl interface the driver will
expose will allow updating the qxl DDX driver to work on it. The new driver
needs to support all revisions of the qxl device.
Btw. Feature has been already proposed as Fedora 18 feature but was postponed
for Fedora 19.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking
by Jaroslav Reznik
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/DualstackNetworking =
https://fedoraproject.org/wiki/Features/DualstackNetworking
* Detailed description
Fedora supports dualstack global networking. That means the computer with
Fedora is connected to internet using both IPv4 and IPv6 protocols. But many
important system services and applications either don't do IPv6, do it
incorrectly, or don't cope with various network conditions.
Unfortunately, while trying to improve IPv6 support, some IPv4 use cases became
broken as well. That's why the goal of this feature is not only to support IPv4,
but to support all possible real-world cases.
Dualstack-ready software must cope with all possible scenarios including
IPv4-only connectivity, IPv6-only connectivity and dual connectivity.
The software must also cope with node-local (aka localhost) networking, which
as been used by software for decades.
Though it would be nice to have all applications in Fedora fixed to work in
any of the scenarios, it is not feasible to test that. Therefore this feature
is about major software used in servers, desktops and laptops. The list of such
applications will be completed over the time.
Bugs related to dualstack networking should be added to the following tracker
bug:
http://bugzilla.redhat.com/show_bug.cgi?id=883152
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=ipv6blocker
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Orphaning xfig
by Stanislav Ochotnicky
I am orphaning xfig. Inkscape supports its file format and it's IMO much better
alternative for current machines. For some reason gstreamer{,1} buildrequires
it. Xfig has a 2 comaintainers, but I am not sure how much time they really have
currently. There are 2 bugs open.
I am ccing gstreamer owners as well.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
11 years, 2 months
