[Pidgin] mmcco modified

[Pidgin]

Page "mmcco" was changed by mmcco
Diff URL: <https://developer.pidgin.im/wiki/mmcco?action=diff&version=91>
Revision 91
Comment: clarify, fix syntax highlighting
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: mmcco
=========================================================================
--- mmcco (version: 90)
+++ mmcco (version: 91)
@@ -176,9 +176,9 @@
 
 OpenBSD's new privilege revocation system call [http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2 pledge(2)] is based on the concept that programs do most of their privileged operations during initialization, eventually dropping into a main loop that is "boring and full of buffer overflows". The `pledge(2)` model therefore allows the process all privileges until it makes the system call. This is fundamentally different from approaches such as App^^Armor's, which have a static privilege list stored outside the program that is always enforced.
 
-The `pledge(2)` model makes more sense for network programs like Pidgin and is easier to implement. In these cases, we trust the ''binary'' to not be malicious, but we don't trust the remote network entities it interacts with, and we don't trust the binary to protect us from them. Many other access control frameworks results attempt to protect the system from potentially malicious binaries, which can add complicating rigidity.
-
-This sort of approach can be used in App^^Armor's through its ``aa_change_hat`` and ``aa_change_profile`` functions. However, this is less elegant and seems rarely used.
+The `pledge(2)` model makes more sense for network programs like Pidgin and is easier to implement. In these cases, we trust the ''binary'' to not be malicious, but we don't trust the remote network entities it interacts with, and we don't trust the binary to protect us from them. Why lock down the process before it interacts with the network? Many other access control frameworks results attempt to protect the system from potentially malicious binaries, which can add complicating rigidity.
+
+This sort of approach can be used in App^^Armor's through its `aa_change_hat` and `aa_change_profile` functions. However, this is less elegant and seems rarely used.
 
 === Code annotations ===
 
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://developer.pidgin.im/wiki/mmcco>
Pidgin <https://pidgin.im>
Pidgin

This is an automated message. Someone added your email address to be
notified of changes on 'mmcco' page.
If it was not you, please report to datallah at pidgin.im.