Bug#898267: [firmware-misc-nonfree] Missing firmware i915/kbl_dmc_ver1_04.bin

2018-07-11 Thread Carlos R. Pasqualini
Hi all

Almost two month past since the last message, and still don't have a
new release of this package, it's a shame since QA informs there is 20
commits since the tag debian/20170823-1. I cannot found any new release
in the Tracker.

Please consider that many people use Testing, or Stable Backports, and
may require this package in sync with the released Kernel, and their
bug reports will result in a better Buster release.


Thanks!!



Bug#690737: at least on 3.10

2013-08-29 Thread Carlos R. Pasqualini
Wow, thank you for your fast answer!


El jue, 29-08-2013 a las 10:31 +0200, Bastian Blank escribió:
> On Wed, Aug 28, 2013 at 09:05:01PM -0300, Carlos R. Pasqualini wrote:
> > can we have this option by default at least on Testing?
> 
> Also for you the question: What does it bring for our users?

The possibility to have a more efficient way of having an AV looking on
the filesystem level for mailware, on our fileservers that runs Debian.

Here we are an University on which we have ~2000 end users, using shared
folders over NFS and Samba on Debian Servers.
So, searching for a way to have clamav on filesystem level we go to:
http://www.clamav.net/lang/en/download/third-party-tools/3rdparty-fs/

* The only open source solution that we can implement there on Debian is
ClamFS which runs on userspace and the few times i have tested it had a
few issues.
* Samba-vscan does not seems to be maintained any more, and i haven't
found anything like that for Samba4 (here, we are studying the deploy of
Samba4, may be using jessy in a near future, so this is a must for us).
* AVfs [http://www.fsl.cs.sunysb.edu/docs/avfs-security04/index.html]
dates from 2003, http://packages.debian.org/wheezy/avfs sems not to be
that project.
* Dazuko has been discontinued in favor of a 'fanotify
implementation' (see
[http://dazuko.dnsalias.org/wiki/index.php/Linux_Submission], where the
developer says "The patches here do not reflect the latest version of
DazukoFS. Because of the lack of interest in DazukoFS from the Linux
community, no further submissions were made. Since then, the
Fedora-backed fanotify project has been accepted into mainline Linux and
could be used as a replacement for DazukoFS") which is where we find
"Skyld AV", which is something like DazukoFS but relying on the fanotify
infrastructure.
* If we can have the kernel to support SktldAV on the stock Debian
Kernel, may be we can get to have an almost working solution on Jessy's
freeze; if that's too optimistic, we can target jessy+1. It seems that
SktldAV is almost stable by now but we need a lot more testing.

> 
> Why does "Skyld AV" fail if it can't actually deny access but only do
> passive observation?

i cannot understand completely your affirmation, may be the original
poster (the developer of "Skyld AV") can bring some better insight on
this.
With passive observation, you mean to scan for virus in a post-write
step? if this is your affirmation, i think you are worng: the hole point
of this type of infrastructures is to prevent the malicious code to been
written on a (may be shared) partition.

> 
> > i have googled around and cannot find any report that this option makes
> > any side effect, may be i'm just looking in the wrong place.
> 
> It is pretty deep in the access control machinery, so it can produce a
> DoS.

Thanks for this! i'll take it into account



Best Regards / Saludos!


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1377805601.17769.38.ca...@capibara.fcal.uner.edu.ar



Bug#690737: at least on 3.10

2013-08-28 Thread Carlos R. Pasqualini
Hi people!!


the subjet of this mail is a realted question:

can we have this option by default at least on Testing?

today, i have installed 3.10 backport kernel for testing Skyld AV and
found that i need to recompile the kernel (i'm using wheezy +
backports):

root@capibara:~# uname -a
Linux capibara 3.10-0.bpo.2-amd64 #1 SMP Debian 3.10.5-1~bpo70+1
(2013-08-11) x86_64 GNU/Linux
root@capibara:~#  grep CONFIG_FANOTIFY /boot/config-$(uname -r)
CONFIG_FANOTIFY=y
# CONFIG_FANOTIFY_ACCESS_PERMISSIONS is not set

may be, as the point on having a unstable/testing distro is to test new
things, we can have a pilot prove of the side efects of turning
CONFIG_FANOTIFY_ACCESS_PERMISSIONS to 'y'

i have googled around and cannot find any report that this option makes
any side effect, may be i'm just looking in the wrong place.

Do we know of any side/negative effect of turning this option to on?


Thanks!


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1377734701.17769.9.ca...@capibara.fcal.uner.edu.ar