Hello,
the ABRT team got an request to replace uploading of core dumps
to the retrace server by providing a fuse-like share with debuginfos [1].
It would be really nice if the security experts could comment on this.
Thank you for considering my request.
Kind regards,
Jakub Filak
1: https://github.com/abrt/abrt/issues/832
Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
>---------------------------------------------------------------
commit 18654176d5d06211ba6393ceaf83afc53080d146
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Wed Aug 13 09:44:05 2014 +0200
Go: Add section on deserialization
In particular, warn about information leakage due to object reuse.
>---------------------------------------------------------------
defensive-coding/en-US/Go.xml | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/defensive-coding/en-US/Go.xml b/defensive-coding/en-US/Go.xml
index 0e44d5e..b5529a6 100644
--- a/defensive-coding/en-US/Go.xml
+++ b/defensive-coding/en-US/Go.xml
@@ -87,4 +87,24 @@
spontaneously.
</para>
</section>
+<section id="chap-Defensive_Coding-Go-Marshaling">
+ <title>Marshaling and marshaling</title>
+ <para>
+ Several packages in the <literal>encoding</literal> hierarchy
+ provide support for serialization and deserialization. The usual
+ caveats apply (see
+ <xref linkend="chap-Defensive_Coding-Tasks-Serialization"/>).
+ </para>
+ <para>
+ As an additional precaution, the <function>Unmarshal</function>
+ and <function>Decode</function> functions should only be used with
+ fresh values in the <literal>interface{}</literal> argument. This
+ is due to the way defaults for missing values are implemented:
+ During deserialization, missing value do not result in an error,
+ but the original value is preserved. Using a fresh value (with
+ suitable default values if necessary) ensures that data from a
+ previous deserialization operation does not leak into the current
+ one. This is especially relevant when structs are deserialized.
+ </para>
+</section>
</chapter>
Hello,
I plan to submit the following text for packaging guidelines regarding
crypto policies. Are there any comments or suggestions?
Since Fedora 21 (http://fedoraproject.org/wiki/Changes/CryptoPolicy)
there are policies for the usage of SSL and TLS cryptographic protocols
that are enforced system-wide. Each application being added in Fedora
must be checked to comply with the policies. Currently the policies are
restricted to applications using GnuTLS and OpenSSL.
* OpenSSL applications: If the application provides a configuration
file that allows to modify the cipher list string, ensure that the
default is "PROFILE=SYSTEM". Otherwise, if the application doesn't have
a configuration file, ensure that there is no default cipher list
specified, or that the default list is set as "PROFILE=SYSTEM".
* GnuTLS applications: If the application provides a configuration file
that allows to modify the cipher priority string, ensure that the
default is "@SYSTEM". Otherwise, if the application doesn't have a
configuration file, ensure that it uses gnutls_set_default_priority(),
or that the default priority string is "@SYSTEM".
Applications utilizing other cryptographic libraries do not adhere to
the system wide crypto policies.
regards,
Nikos