| View previous topic :: View next topic |
| Author |
Message |
tld
Veteran
Joined: 09 Dec 2003
Posts: 1850
|
 Posted: Tue Aug 11, 2015 12:40 am Post subject: |
 |
|
| Anon-E-moose wrote: | And yet another person noticing that the (k)dbus devs are just dismissing any and all criticisms.
At this rate, Linus may just decide to have them on the same footing as BFS, which is NOT included in the kernel, but the patches are easy to apply. |
This actually raises a question I've been meaning to ask:
Since none of this BS has actually been merged into the kernel, what on earth does the new Gentoo kdbus USE flag even do?? Does it pull in patches from these jackasses?
If so, to Steve's point, even in the interest of "choice" in Gentoo, when on earth is a USE flag ever added that pulls in third party patches not even recognized by upstream? I would just hope the sames hoops would be jumped through when it starts getting prohibitively difficult to avoid this crap.
Tom |
|
| Back to top |
|
 |
saellaven
l33t
Joined: 23 Jul 2006
Posts: 655
|
| Posted: Tue Aug 11, 2015 12:52 am Post subject: |
|
|
I think the more enlightening part of Linus post was what he opened with
| Linus wrote: |
On Sun, Aug 9, 2015 at 3:11 PM, Daniel Mack <daniel@zonque.org> wrote:
>
> The kdbus implementation is actually comparable to two tasks X and Y
> which both have their own buffer file open and mmap()ed, and they both
> pass their FD to the other side. If X now writes to Y's file, and that
> is causing a page fault, X is accounted for it, correct?
No.
With shared memory, there's no particularly obvious accounting rules.
In particular, when somebody maps an already allocated page, it's
basically a no-op from a memory allocation standpoint.
The whole "this is equivalent to the user space deamon" argument is
bogus. Shared memory is very very different from just sending messages
(copying the buffers) and is generally much harder to get a handle on.
And thats' what you should be comparing to.
The old "communicate over a unix domain socket" had pretty clear
accounting rules, and while unix domain sockets have some horribly
nasty issues (most are about passing fd's around) that isn't one of
them.
|
David Lang had another key point too, which we've talked about to some degree here in regard to systemd as PID1 in several of the many technical threads we've had shut down over politics,
| David Lang wrote: |
On Sun, 9 Aug 2015, Greg Kroah-Hartman wrote:
> The issue is with userspace clients opting in to receive all
> NameOwnerChanged messages on the bus, which is not a good idea as they
> constantly get woken up and process them, which is why the CPU was
> pegged. This issue should now be fixed in Rawhide for some of the
> packages we found that were doing this. Maintainers of other packages
> have been informed. End result, no one has ever really tested sending
> "bad" messages to the current system as all existing dbus users try to
> be "good actors", thanks to Andy's testing, these apps should all now
> become much more robust.
Does it require elevated privileges to opt to receive all NameOwnerChanged messages on the bus? Is it the default unless the apps opt for something more restrictive? or is it somewhere in between?
I was under the impression that the days of writing system-level stuff that assumes that all userspace apps are going to 'play nice' went out a decade or more ago. It's fine if the
userspace app can kill itself, or possibly even the user it's running as, but being able to kill apps running as other users, let alone the whole system is a problem nowdays.
It may be able to happen in a default system, but this is why cgroups and namespaces have been created, to give the system admin the ability to limit the resources that any one app can consume. Introducing a new mechanism that allows one user to consume resources allocated to another and kill the system without providing a kernel level mechanism to limit the damage (as opposed to fixing individual apps) seems rather short-sighted at best.
|
So, once again, we see that the systemd/kdbus crew have absolutely no clue about security, system level programming, etc.
Now, mind you, the stated purpose of systemd is that "systemd talks to the kernel, everything else talks to systemd" and the way everything talks to systemd, is through kdbus... and not only is kdbus a massive mess full of exploits (some potential privilege escalation problems in addition to "minor" things like apps being able to DOS a system), but these people don't have enough experience to even acknowledge the problem when pointed out to them.
Worse, in an effort to try to push kdbus into the kernel, the latest versions of systemd are pushing it on users by default.
Even more crazy, systemd as PID1 is tied into everything else on the system, meaning you have a privileged program touching everything that is touching a bus that is full of holes too. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Aug 11, 2015 11:59 am Post subject: |
|
|
| saellaven wrote: | So, once again, we see that the systemd/kdbus crew have absolutely no clue about security, system level programming, etc.
Now, mind you, the stated purpose of systemd is that "systemd talks to the kernel, everything else talks to systemd" and the way everything talks to systemd, is through kdbus... and not only is kdbus a massive mess full of exploits (some potential privilege escalation problems in addition to "minor" things like apps being able to DOS a system), but these people don't have enough experience to even acknowledge the problem when pointed out to them.
Worse, in an effort to try to push kdbus into the kernel, the latest versions of systemd are pushing it on users by default.
Even more crazy, systemd as PID1 is tied into everything else on the system, meaning you have a privileged program touching everything that is touching a bus that is full of holes too. |
Lindows is back ;-)
I found this part interesting, as we discussed the ballooning memory issue at the beginning of this thread (not in quotes as it gets messy, and it's my post):
--
The ballooning memory requirements were first raised here: | David Lamparter wrote: | | This sounds like a terribly nice way to f*ck the entire D-Bus system by having one broken (or malicious) desktop application. What's the intended way of coping with users that block the socket by not reading? |
to which we get a pretty lame response: | Javier Martinez Canillas wrote: | this problem exists with current D-bus implementation. If a malicious desktop application doesn't read its socket then the messages sent to it will be buffered in the daemon:
https://bugs.freedesktop.org/show_bug.cgi?id=33606
dbus-daemon memory usage will balloon until max_incoming_bytes/max_outgoing_bytes limit is reached (1GB for session bus in default configuration)..
It only works because not many applications are broken and user-space memory is virtualized. But if you bypass the daemon and use a multicast transport layer (as in our multicast Unix socket implementation) you don't have that much memory to buffer the packets. |
Note this latter problem still applies when bringing kdbus into the kernel, and further that despite the excellent analysis on that bug, not one step has been taken to address the fundamental design flaw; the last comment from a known hal/udev/systemd developer with any content is from January 2011, and indicates serious miscomprehension issues, as he witters on about uid.
It's perfectly simple: stop pretending you can provide a square triangle.
--
However that is still baked into the whole undesign; if you take away that idiotic requirement, you can simply use TIPC, as they were advised to do in March 2012.
That seems like a much better idea.
In fact what they were told in 2012 still seems to be apposite:
| David Miller wrote: | I really don't want to apply this stuff: it looks bloated, complicated, and there is another avenue for doing what you want to do.
Applications have to change to support the new multicast facilities, so they can equally be changed to use a real transport that already supports multicasting. |
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Aug 14, 2015 10:54 am Post subject: |
|
|
| tld wrote: |
Since none of this BS has actually been merged into the kernel, what on earth does the new Gentoo kdbus USE flag even do?? Does it pull in patches from these jackasses?
If so, to Steve's point, even in the interest of "choice" in Gentoo, when on earth is a USE flag ever added that pulls in third party patches not even recognized by upstream? I would just hope the sames hoops would be jumped through when it starts getting prohibitively difficult to avoid this crap. |
The real problem is not that it's not recognize by upstream, it is because upstream recognize this cannot be include (yet/as-is) for security reason.
I think that use flag is/should pull the patches.
It should just be kick out if we have a real QA team ; as this patch will not only gave more "choice", but security issue (and you don't even need to dig that yourself if you trust lklm devs).
But maybe that useflag is hardmask, no idea.
Do they add this useflag to vanilla kernel too? |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9330
|
| Posted: Fri Aug 14, 2015 10:59 am Post subject: |
|
|
| You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Aug 14, 2015 10:39 pm Post subject: |
|
|
| genstorm wrote: | | You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources. |
Seems to me it would be better to have an explicit USE=kdbus flag, rather than lump it in with "experimental".
That would help both sides: people who want to avoid it, and people who want to depend on it. |
|
| Back to top |
|
|
davidm
Guru
Joined: 26 Apr 2009
Posts: 557
Location: US
|
| Posted: Fri Aug 14, 2015 11:04 pm Post subject: |
|
|
| steveL wrote: | | genstorm wrote: | | You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources. |
Seems to me it would be better to have an explicit USE=kdbus flag, rather than lump it in with "experimental".
That would help both sides: people who want to avoid it, and people who want to depend on it. |
I'm probably going to give it a shot if it makes it to the stable kernel since I'm already using systemd but I was thinking about this as well and it seemed to me that we would probably have to introduce a kdbus use flag. Otherwise wouldn't other programs try pulling in userspace dbus unnecessarily as a redundant dependency? I guess you might also read the current kernel configuration but that would be even more messy. I'm not a developer but was just wondering how it might all fit together in Gentoo and considered there might be issues.
On the politics of it all, I just appreciate Gentoo allowing for a CHOICE and though I use systemd I think upstream should also try to respect that by not trying to cram it down users' throats. I sincerely hope they do not go that route. |
|
| Back to top |
|
|
roki942
Apprentice
Joined: 18 Apr 2005
Posts: 285
Location: Seattle
|
| Posted: Sat Aug 15, 2015 1:21 am Post subject: |
|
|
| steveL wrote: | | genstorm wrote: | | You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources. |
Seems to me it would be better to have an explicit USE=kdbus flag, rather than lump it in with "experimental".
That would help both sides: people who want to avoid it, and people who want to depend on it. |
| Quote: | Keeping with the theme of ‘Gentoo is about choice” I’ve added the ability for users to include kdbus into their gentoo-sources kernel. I wanted an easy way for gentoo users to test the patchset while maintaining the default installation of not having it at all.
In order to include the patchset on your gentoo-sources you’ll need the following:
1. A kernel version >= 4.1.0-r1
2. the ‘experimental’ use flag
3. the ‘kdbus’ use flag
I am not a systemd user, but from the ebuild it looks like if you build systemd with the ‘kdbus’ use flag it will use it.
Please send all kdbus bugs upstream by emailing the developers and including linux-kernel@vger.kernel.org in the CC .
|
http://www.mpagano.com/blog/?p=208 |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9330
|
| Posted: Sat Aug 15, 2015 7:35 am Post subject: |
|
|
Guys, the kdbus use flag was mentioned right here in the thread. Does it hurt to do this
| Code: | | $ equery u gentoo-sources |
before post? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6200
Location: Dallas area
|
| Posted: Sat Aug 15, 2015 9:21 am Post subject: |
|
|
| Code: | * Found these USE flags for sys-kernel/gentoo-sources-4.0.5:
U I
- - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first
half of bootstrapping [make stage1]
- - deblob : Remove binary blobs from kernel sources to provide libre license compliance.
- - experimental : Apply experimental patches; for more information, see
"https://wiki.gentoo.org/wiki/Project:Kernel/Experimental".
- - symlink : Force kernel ebuilds to automatically update the /usr/src/linux symlink |
| Code: | * Found these USE flags for sys-kernel/gentoo-sources-4.1.5:
U I
- - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first
half of bootstrapping [make stage1]
- - experimental : Apply experimental patches; for more information, see
"https://wiki.gentoo.org/wiki/Project:Kernel/Experimental".
- - kdbus : Apply the kdbus patch. This also requires the "experimental" use flag.
- - symlink : Force kernel ebuilds to automatically update the /usr/src/linux symlink |
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6200
Location: Dallas area
|
| Posted: Sat Aug 15, 2015 9:23 am Post subject: |
|
|
| saellaven wrote: | I think the more enlightening part of Linus post was what he opened with
... |
The whole post was good, and I notice that not one response to it from any of the (k)dbus devs including GKH.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Aug 15, 2015 11:36 am Post subject: |
|
|
Cheers roki.
genstorm: No ofc not; does it hurt to explain yourself more fully instead of point-scoring? you have my sympathy. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9330
|
| Posted: Sat Aug 15, 2015 3:47 pm Post subject: |
|
|
| This is a forum; I don't think I need to use more words when the context is right there above my post, as I was answering to krinn... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Aug 30, 2015 4:23 pm Post subject: |
|
|
| Yes, well I believe you.. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54744
Location: 56N 3W
|
| Posted: Sun Aug 30, 2015 4:27 pm Post subject: |
|
|
Moved the systemd absorbs sudo discussion to The Politics of systemd as its not kdbus related -yet.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9330
|
| Posted: Sun Aug 30, 2015 4:46 pm Post subject: |
|
|
| steveL wrote: | | Yes, well I believe you.. |
So you disagree about context now? |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Tue Sep 01, 2015 12:43 am Post subject: |
|
|
http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04789.html
| David Herrmann wrote: | It means kdbus messages carry information about the sender, which LSMs
might prevent you to read via /proc. Just like you can send dbus
messages to a peer, which LSM-enhanced dbus-daemon might not allow. If
you use LSMs, we clearly advise you to wait for kdbus to gain LSM
support. We explicitly support legacy dbus1-compat for exactly such
reasons. |
I'm not too knowledgeable on the security setups, so someone may be able to correct my understanding. However, this is sounding like kdbus is specifically working to break the security policies that is put in place.
How I see it, if LSM or some other security policy blocks something, shouldn't that mean it shouldn't be bypassed? |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3525
|
| Posted: Tue Sep 01, 2015 1:22 am Post subject: |
|
|
| ct85711 wrote: | http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04789.html
| David Herrmann wrote: | It means kdbus messages carry information about the sender, which LSMs
might prevent you to read via /proc. Just like you can send dbus
messages to a peer, which LSM-enhanced dbus-daemon might not allow. If
you use LSMs, we clearly advise you to wait for kdbus to gain LSM
support. We explicitly support legacy dbus1-compat for exactly such
reasons. |
I'm not too knowledgeable on the security setups, so someone may be able to correct my understanding. However, this is sounding like kdbus is specifically working to break the security policies that is put in place.
How I see it, if LSM or some other security policy blocks something, shouldn't that mean it shouldn't be bypassed? |
But... but... but... it's systemd, so of course it's OK.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Tue Sep 01, 2015 7:33 pm Post subject: |
|
|
| ct85711 wrote: | http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04789.html
| David Herrmann wrote: | It means kdbus messages carry information about the sender, which LSMs
might prevent you to read via /proc. Just like you can send dbus
messages to a peer, which LSM-enhanced dbus-daemon might not allow. If
you use LSMs, we clearly advise you to wait for kdbus to gain LSM
support. We explicitly support legacy dbus1-compat for exactly such
reasons. |
I'm not too knowledgeable on the security setups, so someone may be able to correct my understanding. However, this is sounding like kdbus is specifically working to break the security policies that is put in place.
How I see it, if LSM or some other security policy blocks something, shouldn't that mean it shouldn't be bypassed? |
The answer is
| Andy_Lutomirski wrote: | > If
> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.
This is not an acceptable attitude for security.
There are so many things wrong with your statement that I'll limit
myself to one of them: Fedora 23/Rawhide, which is the *reference*
platform, uses SELinux.
--Andy |
Which pretty much looks like the end of Kdbus in kernel implementing a dbus1-compat feature then. At least some more time to wait for mainline kdbus inclusion until "kdbus to gain LSM support" (David Herrmann announces future work to be done?). At this point the most sincere way of a workaround would be to configure the kernel exclusively "Kdbus OR LSM", which for sure will amuse everybody loughing out loud. Just having heard the Redhat goals talk to a Fedora audience (via youtube - I am not a member of that herd): One of their main objectives these days is hardening the kernel (mitigating security flaws they name it (*)). This a key business goal I cannot imagine Redhat will compromize on that.
(*)"mitigating security flaws" may or may not be kernel related though. But interestingly you can see discussion about gresecurity on the kernel mailing list. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Sep 02, 2015 4:54 pm Post subject: |
|
|
Some context sheds light on just why this is so brain-dead at conception:
| Andy Lutomirski wrote: | I spotted this: | Code: | +/**
+ * kdbus_proc_permission() - check /proc permissions on target pid
+ * @pid_ns: namespace we operate in
+ * @cred: credentials of requestor
+ * @target: target process
+ *
+ * This checks whether a process with credentials @cred can access information
+ * of @target in the namespace @pid_ns. This tries to follow /proc permissions,
+ * but is slightly more restrictive.
+ *
+ * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
+ */
+static unsigned int kdbus_proc_permission(const struct pid_namespace *pid_ns,
+ const struct cred *cred,
+ struct pid *target) |
That code ended up in a pull request, although AFAICT it was never in
any patch email sent to me or to any public mailing list. I suspect
it was at least partially a response to one of my old reviews. |
Note the inexcusable lack of transparency in adding a patch, which just happens to nullify existing kernel-security:
| Andy Lutomirski wrote: | I haven't checked the context in which it's used, but in order for
kdbus_proc_permission to do what it claims to do, it appears to be
missing calls to security_inode_permission and
security_file_permission. |
To which we get the lame response:
| David Herriman wrote: | Both are expected to be added by lsm patches (both hooks you mentioned
are empty if no lsm is selected). |
iow: by default we open a gaping attack vector, on every machine running kdbus.
Only if you specifically select an LSM, will there be even a remote chance of just the level of security we expect as minimum.
Note that would depend on your provider, and in today's scene, if you trust these "developers" you're a fool, afaic.
They've already shown stunning levels of incompetence, arrogance, and plain stupidity, as well as clearly trying to enforce vendor lock-in to RedHat, across the whole of binary Linux.
And if you don't happen to be using LSMs, what happens in this stunning new vision of a Brave New Lennux? You get screwed, only we lie to you and tell you we're "slightly more restrictive" than existing practice, again pretending to more competence than in-play.
Accept this into the kernel? Don't make me laugh; what needs to happen is a final big NACK to the whole idea, and further to the whole team involved, who clearly don't have the experience to design a sand-castle, let alone the "core of the Linux OS userland" (akin to the various BSDs' userlands, which are in reality made up of many, ecosystem-respecting components, from separate projects.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Sep 02, 2015 5:04 pm Post subject: |
|
|
| ulenrich wrote: | | Just having heard the Redhat goals talk to a Fedora audience (via youtube - I am not a member of that herd) |
Sounds an awful lot like you work for RedHat.
Feel free to follow up in "the politics of". |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Wed Sep 02, 2015 7:42 pm Post subject: |
|
|
@steveL, if you'd know where I work, you would not believe my interest in Gentoo and Debian as a hobby.
/Me, having a very positive view on Redhat, I offered a bet: Redhat will not compromize on security.
| steveL wrote: | | Sounds an awful lot like you work for RedHat. |
Sounds like an awful lot of people have worked for Redhad and got fired. Or they didn't get a job they desired ... |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Wed Sep 02, 2015 9:40 pm Post subject: |
|
|
| Quote: | Clarification: Fedora Rawhide only. The kdbus code is not included in
the F23 kernel.
Your point otherwise stands. I just don't want Phoronix or someone
else getting confused and thinking Fedora 23 will ship with kdbus. It
will not. |
http://lkml.iu.edu/hypermail/linux/kernel/1509.0/00414.html
It's interesting, that RH won't even use kdbus in Fedora. They want to push it into the kernel, but yet they won't even use it in their products. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3525
|
| Posted: Wed Sep 02, 2015 9:54 pm Post subject: |
|
|
| ct85711 wrote: | | Quote: | Clarification: Fedora Rawhide only. The kdbus code is not included in
the F23 kernel.
Your point otherwise stands. I just don't want Phoronix or someone
else getting confused and thinking Fedora 23 will ship with kdbus. It
will not. |
http://lkml.iu.edu/hypermail/linux/kernel/1509.0/00414.html
It's interesting, that RH won't even use kdbus in Fedora. They want to push it into the kernel, but yet they won't even use it in their products. |
Hmmmm..... Years back people tried to interpret IBM's frequently-inconsistent actions, and had a really rough time of it. There was another point of view that was much closer to reality - that IBM was not one big unified company. There were many factions inside, each with its own agenda.
I suspect that the same could be said of just about ANY company, or at the very least any company not still under the sway of it's major charismatic founder / re-invigorator. So I'm sure part of RedHat sees kdbus and systemd as a way to be the new Microsoft. I'm equally sure another part of RedHat understands the security implications.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Sep 03, 2015 7:53 am Post subject: |
|
|
| steveL wrote: | | Sounds an awful lot like you work for RedHat. |
| ulenrich wrote: | | Sounds like an awful lot of people have worked for Redhat and got fired. Or they didn't get a job they desired ... |
Before I deal with your jibe, I must point out that it sounds even more like you work for RH now.
Precisely because you're trying to get a rise out of me; the insult is based on "insider" knowledge of how RH works.
As for your jibe, no: you're way off base. Never worked for them, never applied, never been interested.
Trying to be smart and avoid the question, all the while having a dig at me isn't working.
It just makes you look dishonest.
No wonder you have a "very positive view on Redhat".
As for me, I now think of you as a liar.
Good day. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
