The audit support required by these can't be compiled in without it
being enabled. It's useless crap for anyone who isn't working for a
bureaucracy and it spams the logs. It is also completely broken with
namespaces, so it doesn't work at all with containers or application
sandboxes.
If and when t
On 02/04/14 06:10 PM, David C. Rankin wrote:
> On 04/02/2014 04:44 AM, Neal Oakey wrote:
>> What do you think? Imho we should keep follow Debian here. Other
>>> solutions would be to patch it back in or ship a separate optional
>>> package; though that might be impossible for nss.
>>>
>>> Greetings
I really do hope the manpower becomes available to complete the code
cleanup and other things necessary to bring CAcert into the major
browsers and back into the Arch certificate bundle. From looking at the
options, CAcert is, as far as I know, the only truly free certificate
authority available an
On 04/02/2014 04:44 AM, Neal Oakey wrote:
> What do you think? Imho we should keep follow Debian here. Other
>> solutions would be to patch it back in or ship a separate optional
>> package; though that might be impossible for nss.
>>
>> Greetings,
>>
>> Pierre
>>
I usually agree with Pierre, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2014 09:45 AM, Arthur Țițeică wrote:
> În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris:
>> I want to trim our kernel down to what we actually support.
>
>> 1) Once we agreed to disable one LSM, everyone else said "we c
Hi,
here you have some more detailed informations (see quote).
Greetings,
Neal
Am 02.04.2014 23:40, schrieb Benny Baumann:
> Hi,
>
> Am 02.04.2014 18:33, schrieb Neal Oakey:
>> mit freundlichen Gruessen / best regards
>> Neal Thomas Oakey
>> CAcert Assurer, CAcert Event Organisation
>> CAcert.or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2014 04:00 PM, Arthur Țițeică wrote:
> My conclusions so far: there's no difference between the stock -ARCH kernel
> and my -NOLSM build in which I disabled all LSMs (and hence audit).
>
> Note: the final test with 50 files for the rotat
All,
The upgrade to apache 2.4 can present a real challenge for those relying on
mod_php, mod_ssl and vhosts. On 2/27 on Arch-dev, Pierre suggested: "Anyway, I
suggest in the end we should post an announcement on the front page." He was
right.
Having a few moments today to bring a production
Am 02.04.2014 19:57, schrieb Leonid Isaev:
> Hi,
>
> On a current [testing] installation, there are several timer symlinks
> in /usr/lib/systemd/system/multi-user.target.wants (shipped with logrotate,
> man-db, etc.). What is the reason for choosing multi-user.target instead of
> timers.targ
Hi,
On a current [testing] installation, there are several timer symlinks
in /usr/lib/systemd/system/multi-user.target.wants (shipped with logrotate,
man-db, etc.). What is the reason for choosing multi-user.target instead of
timers.target?
Thanks,
--
Leonid Isaev
GnuPG key fingerprint:
On Wed, 02 Apr 2014 18:47:52 +0200
Nowaker wrote:
> > There may be a transparent proxy in your routing chain that strips
> > compression in order to run a virus scan.
>
> Time for SSL-securing Arch Linux repos to prevent any sort of
> man-in-the-middle attacks? Even such trivial things like com
Am 02.04.2014 19:01, schrieb Daniel Micay:
On 02/04/14 01:00 PM, Daniel Micay wrote:
On 02/04/14 12:47 PM, Nowaker wrote:
There may be a transparent proxy in your routing chain that strips
compression in order to run a virus scan.
Time for SSL-securing Arch Linux repos to prevent any sort of
m
On 02/04/14 01:00 PM, Daniel Micay wrote:
> On 02/04/14 12:47 PM, Nowaker wrote:
>>> There may be a transparent proxy in your routing chain that strips
>>> compression in order to run a virus scan.
>>
>> Time for SSL-securing Arch Linux repos to prevent any sort of
>> man-in-the-middle attacks? Eve
On 02/04/14 12:47 PM, Nowaker wrote:
>> There may be a transparent proxy in your routing chain that strips
>> compression in order to run a virus scan.
>
> Time for SSL-securing Arch Linux repos to prevent any sort of
> man-in-the-middle attacks? Even such trivial things like compression
> strippi
There may be a transparent proxy in your routing chain that strips
compression in order to run a virus scan.
Time for SSL-securing Arch Linux repos to prevent any sort of
man-in-the-middle attacks? Even such trivial things like compression
stripping, or image optimization often performed by mo
It's becoming clearer that CAcert isn't going to be passing a third
party audit any time soon. Our only view into it is the open-source code
they've made available, and messy wiki documentation. The quality of the
code is not exactly comforting - whoever wrote most of it didn't seem to
be aware of
Am 02.04.2014 17:56, schrieb Magnus Therning:
On Wed, Apr 02, 2014 at 10:16:04AM +0200, Magnus Therning wrote:
On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning wrote:
On a newly set up system I've added the [haskell-core] repo [1], but
get stuck with the following message from `pacman`:
%
On Wed, Apr 02, 2014 at 10:16:04AM +0200, Magnus Therning wrote:
> On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning wrote:
> > On a newly set up system I've added the [haskell-core] repo [1], but
> > get stuck with the following message from `pacman`:
> >
> >
> > % sudo pacman -Syy
> > error:
On 02/04/14 11:31 AM, Neal Oakey wrote:
> Hi,
>
> well until now all of this wasn't a problem, so why has it now become one?
It's becoming clearer that CAcert isn't going to be passing a third
party audit any time soon. Our only view into it is the open-source code
they've made available, and mes
Hi,
well until now all of this wasn't a problem, so why has it now become one?
And well if you have a look at startssl, well they may be offering free
certs but only single domain and just use the plain "things".
* It doesn't allow commercial usage
* "only" valid for 1 year
* located in I
Hello.
testing/linux-3.14-1 x86-64
The kernel panicked while starting X. The errors dumped pointed to
the radeon module.
Is anyone else seeing this regression?
According to Daniel Micay:
# Until then, there are plenty of other certificate authorities with free
# certificates that are also included in every major browser / operating
# system. For example:
#
# https://www.startssl.com/?app=1
I initially became interested in CAcert not only because of its f
On 02/04/14 05:44 AM, Neal Oakey wrote:
> Hi all,
>
> because I can't send this to the arch-dev-public mailing list I will
> send this here:
>
> In my opinion, only because Debian drops the support for something this
> doesn't mean that we should do the same.
>
> And if you look at the Bugreport
Hi all,
because I can't send this to the arch-dev-public mailing list I will
send this here:
In my opinion, only because Debian drops the support for something this
doesn't mean that we should do the same.
And if you look at the Bugreport you will notice that the Information on
which Debian is b
Am 02.04.2014 02:51, schrieb Genes Lists:
> On 04/01/2014 06:44 PM, Thomas Bächler wrote:
>
>> Okay, pushed everything to [testing] and [community-testing].
>
> This may just be a mirror sync issue but I am seeing this:
> pacman -Syu
> ...
> looking for inter-conflicts...
> error: failed to prepa
Really good job on the 3.14 release! Thanks for keeping everything
clean and simple.
- Alexander Rødseth / xyproto
On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning wrote:
> On a newly set up system I've added the [haskell-core] repo [1], but
> get stuck with the following message from `pacman`:
>
>
> % sudo pacman -Syy
> error: haskell-testing: signature from "ArchHaskell (Magnus Therning)
> " is invalid
>
On a newly set up system I've added the [haskell-core] repo [1], but
get stuck with the following message from `pacman`:
% sudo pacman -Syy
error: haskell-testing: signature from "ArchHaskell (Magnus Therning)
" is invalid
:: Synchronising package databases...
core
28 matches
Mail list logo