similar to: is tinc vulnerable to this?

What would be a good POP daemon to use? I know there are a few in the mail ports. Are they any good? What I mean by good is 'secure as possible' (is there really such thing as being totally secure / invulnerable?) Cheers

On Tue, 2006-02-21 at 14:58 -0800, rsync2eran@tromer.org wrote: > A year ago we discussed the strength of the MD4 hash used by rsync and > librsync, and one of the points mentioned was that only collision > attacks are known on MD4. Could you please forward this into the bug tracker so it's not lost? -- Martin -------------- next part -------------- A non-text attachment was

Hiya, I sent this bugfix to the asterisk-dev mailing list, and modified it as I noticed side effects, but now it appears to be finished. Nobody seemed to notice it there, so I thought I'd post here, as it seems to be something that will be needed as people update to the latest CVS version. So...read on :) Ted programmer_ted@hotmail.com P.S. Read to the very end. The original bugfix

... Looking for a recommendation for a commercial threat management package. ( Think antivirus / antispy / anti-rootkit -- all rolled into one engine ), similar to this product: http://usa.kaspersky.com/products_services/work-space-security.php, which currently only supports one kernel for FC6, and RHEL4, officially. Here's the background. Need to make a decision and investment for a

The LLVM 2.8 branches have been created! We will be conducting several rounds of testing of this branch during September. See http://llvm.org/ for a tentative schedule. What this means for you As I mentioned in a previous e-mail, the branch is still open for code submissions. However there are a few rules that we need to adhere to: No new features are allowed, no matter how trivial they may be.

On Tue, 2015-02-10 at 15:04 -0700, Warren Young wrote: > > On Feb 9, 2015, at 12:12 PM, John R Pierce <pierce at hogranch.com> wrote: > > > > On 2/9/2015 11:06 AM, Always Learning wrote: > >> The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF > >> shows every page appears to be readable. 11 pages devoted to BASH. > >>

Hello everyone, I have run into the same issue which the fname-convert patch solves: http://rsync.samba.org/ftp/unpacked/rsync/patches/fname-convert.diff i.e. rsyncing between and latin 1 and utf-8 locales. First I'd really like to thank Eran Tromer for providing the patch as this fixes my immediate issue! I've attached an updated version which applies to the rsync-2.6.5 release and

Hi, One feature missing from rsync, and requested on this list before, is on-the-fly conversion of filename character encoding. For example, I often need to sync files having Hebrew filenames from a UTF-8 system (Linux) to an ISO8859-8 system (Cygwin on Windows 2000 using the non-Unicode Win32 interface). Other circumstances surely abound. Attached is a patch against rsync 2.6.2 that adds an

Hi, The following lines in compat.c are rather imprudent: if (read_batch || write_batch) checksum_seed = 32761; else checksum_seed = time(NULL); write_int(f_out,checksum_seed); Setting checksum_seed to a constant in batch mode means block collisions are reproducible and predictable. Thus, some files will be permanently "unlucky" in batch mode and will

Greetings, I'd like to propose a new option to rsync, which causes it to read device files as if they were regular files. This includes pipes, character devices and block devices (I'm not sure about sockets). The main motivation is cases where you need to synchronize a large amount of data that is not available as regular files, as in the following scenarios: * Keep a copy of a block

Any feedback on this patch and the possibility of getting it into CVS or the patches directory? Thanks, Craig ---------- Forwarded message ---------- To: jw schultz <jw@pegasys.ws> From: Craig Barratt <cbarratt@users.sourceforge.net> cc: rsync@lists.samba.org Date: Sat, 01 May 2004 17:06:10 -0700 Subject: Re: setting checksum_seed jw schultz writes: > > > There was some

Hello, Sometime ago min rsa key length was increased to 1024 bit and i have a little understanding problem with this. I hope somebody with some crypto-experience can enlighten me. To make that clear, that is not about allowing lower keys in general. Personally i would tend to use even longer keys(2048bit+). However Due nature of RSA-algorithm in case of 1024bit this might result in a key

Hello I have currently a larger network deployed using 1.1pre11. I have now tried to use 1.1pre14 on a remote system, but I have problems to make it work with compression enabled. It appears that a 1pre14 client cannot talk to a 1.1pre11 server with compression enabled, even though the tunnel is being established with no errors. I have tried both lzo and zlib with various levels, none works.

All nodes was connected both 1.1pre10 and 1.1pre11 before "tinc -n vpn restart" at Node 1. Shouldnt at least the 1.1pre10 nodes connect again? 2015-05-18 23:39 GMT+02:00 Guus Sliepen <guus at tinc-vpn.org>: > On Mon, May 18, 2015 at 11:04:09PM +0200, ?smund Rabbe wrote: > > > One of the nodes (Node5) stopped working a while ago (2 - 3 weeks or so), > > other

Tinc 1.0 3 control masters Many service hosts Laptop (road warrior) The control masters have the public keys for the service hosts and the laptop so that they can join the network. How can I prevent the laptop user to connect additional boxes to the network? In my view he can simply add new 'foreign' hosts and specify connectTo to point to the laptop. As keys are exchanged automatically

Hi. I'm in desperate need of some good advice. I have a tinc network with 16 nodes. It's a star topology where all nodes are connecting to the one node (Node1) that have a static IP. Node 1 accepts incomming connections Node 2 through 16 connects to Node1 One of the nodes (Node5) stopped working a while ago (2 - 3 weeks or so), other than that everything was working fine. Today I

On Thu, Dec 10, 2015 at 10:15:19AM +0100, Samuel Thibault wrote: > I did get a bit more than a hundred packets in the queue at 800Mbps. But > we can reduce to 64, yes. I wouldn't recommend using a static buffer, > since we'd want to go threaded at some point. Allocating an array on the > stack is very cheap anyway. I assumed that one would only get more than 1 packet at a

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now

On Mon, Jan 05, 2015 at 08:10:48AM -0700, Lance Fredrickson wrote: > Allowing tinc to run without RSA keys is a very big > bonus for us embedded device users. We have a limited amount of nvram space > for storage (tomato firmware). RSA keys took up quite a bit, so being able > to run using only ED25519 makes tinc very appealing for this platform, and > saves tons of space for more