Pinging init.as (American Samoa)

[mplsgrant]

What happened?

I put the emacs cursor on the word init.as and I press C-x b which I have mapped to helm-mini. Instead of bringing up helm-mini, I get a message which says Pinging init.as (American Samoa). Changing the word to init.us, for example, will not hang on that message, but will briefly reach out ostensibly to ping init.us.

Instead of this, I expect helm-mini to pop up, and I don't expect helm to reach out to websites.

How to reproduce?

Use the following configuration, and perform C-x b on the word init.as within the scratch buffer.

early-init.el

( setq package-enable-at-startup nil)

init.el

(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(straight-use-package 'use-package)
(setq use-package-always-ensure t)

(use-package helm
  :straight t
  :init (helm-mode t)
  :bind (("M-x"     . helm-M-x)
         ("C-x C-f" . helm-find-files)
         ("C-x b"   . helm-mini)     ;; See buffers & recent files; more useful.
         ("C-x r b" . helm-filtered-bookmarks)
         ("C-x C-r" . helm-recentf)  ;; Search for recently edited files
         ("C-c i"   . helm-imenu)
         ("C-h a"   . helm-apropos)
         ;; Look at what was cut recently & paste it in.
         ("M-y" . helm-show-kill-ring)

         :map helm-map
         ;; We can list ‘actions’ on the currently selected item by C-z.
         ("C-z" . helm-select-action)
         ;; Let's keep tab-completetion anyhow.
         ("TAB"   . helm-execute-persistent-action)
         ("<tab>" . helm-execute-persistent-action)))

(use-package helm-ag
  :straight t)

Helm Version

Master branch

Emacs Version

Emacs-28/29

OS

GNU/Linux

Relevant backtrace (if possible)

No response

Minimal configuration

• [X] I agree using a minimal configuration

[thierryvolpiatto]

mplsgrant @.***> writes:

What happened?

I put the emacs cursor on the word init.as and I press C-x b which I have mapped to helm-mini. Instead of bringing up helm-mini, I get a message which says Pinging init.as (American Samoa) . Changing the word to init.us, for example, will not hang on that message, but will briefly reach out ostensibly to ping init.us.

Thanks, I could reproduce.

The problem is comming from ffap-guesser. We stop using it after too many bugs and use instead helm-ffap-guesser, but we use it only in helm-files.

However now in emacs-28 it seems ffap is triggered from something else but I can't find what at the moment.

I see that Emacs-29 fixed it by setting ffap-machine-p-known to 'accept' instead of 'ping', IIRC older emacs was setting it to 'reject to fix this kind of problem.

See commit:

,----	commit 9abf841429257a3e1008bedc4d857ea7a25ab9a6	Author: Stefan Kangas	Date: Fri Jul 8 12:04:17 2022 +0200
Stop ffap-machine-at-point from pinging random hosts
Having this on by default is highly problematic from a security and
privacy standpoint, as it risks having outgoing traffic that could
potentially reveal sensitive data (passwords, names, etc.).
It also seems to be causing issues for users, see e.g.
https://github.com/emacs-helm/helm/issues/648
* lisp/ffap.el (ffap-machine-p-known): Change default to 'accept'.

`----

So for now I suggest to set it to 'accept' or 'reject' in your init file until I find the source of the problem i.e. What is calling ffap-guesser under the hood?

It is called nowhere from helm, I guess it is called from an Emacs internal function we use in Helm, but still don't know wich one.

-- Thierry

[thierryvolpiatto]

I finally found what is triggering ffap. We are calling ffap-guess-file-name-at-point indirectly by calling file-name-at-point-functions which contains it by default. Should be fixed now by let binding ffap-machine-p-known. Thanks again to catch this.

[mplsgrant]

Thank you for the quick response, and I am happy to help by submitting these kinds of issues.

I added the following to my init.el:

(setq ffap-machine-p-known 'reject)

It seems to have solved the immediate problem; however, I do feel uneasy knowing that ffap may still lurk out there waiting to send my text to websites at its discretion.

[mplsgrant]

I noticed the fix uses the following code:

(setq ffap-machine-p-known 'accept)

Should I set it to reject or accept?

[thierryvolpiatto]

mplsgrant @.***> writes:

I noticed the fix uses the following code:

(setq ffap-machine-p-known 'accept)

Should I set it to reject or accept?

Don't know, I used 'accept' because it is what they use actually on Emacs-29, in the past they used 'reject' before reenabling to 'ping' :-( in Emacs-28.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: @.***>

-- Thierry

[thierryvolpiatto]

mplsgrant @.***> writes:

Thank you for the quick response, and I am happy to help by submitting these kinds of issues.

I added the following to my init.el:

(setq ffap-machine-p-known 'reject)

It seems to have solved the immediate problem; however, I do feel uneasy knowing that ffap may still lurk out there waiting to send my text to websites at its discretion.

Agree, in addition it is a pain for package developers to deal with this, I spent a lot of time along the last years to fix issues with this (see all the user helm-ff-* vars in helm-files that handle ffap behavior). We use helm-ffap-guesser in helm instead of ffap-guesser to fix this issue.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: @.***>

-- Thierry

[mplsgrant]

Thanks again. I'll close this as it seems to me to be resolved.

[thierryvolpiatto]

Thierry Volpiatto @.***> writes:

mplsgrant @.***> writes:

I noticed the fix uses the following code:

(setq ffap-machine-p-known 'accept)

Should I set it to reject or accept?

Don't know, I used 'accept' because it is what they use actually on Emacs-29, in the past they used 'reject' before reenabling to 'ping' :-( in Emacs-28.

I just looked at ffap-machine-p code, when ffap-machine-p-known is 'accept', the function return 'accept' and with 'reject' it returns nil, other values launch a network process i.e. a ping. So both values reject and accept are safe.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: @.***>

-- Thierry

[thierryvolpiatto]

I just looked at ffap-machine-p code, when ffap-machine-p-known is 'accept', the function return 'accept' and with 'reject' it returns nil, other values launch a network process i.e. a ping. So both values reject and accept are safe.

This assuming you kept the default value (reject) for both ffap-machine-p-local and ffap-machine-p-unknown. If unsure set them in your init file to be safe.

-- Thierry

[mplsgrant]

I went ahead and added a setq for p-local and p-unkown just to be safe.

Also, earlier I had poked around over in an emacs-release repo and I agree with your conclusion regarding the safeness of reject and accept.

[ncaq]

I noticed this problem today. I have the exact same problem. The version of helm is 20230129. The version of Emacs is GNU Emacs 28.2.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2023-02-06. I rewrote (t ffap-machine-p-known) to (t (print ffap-machine-p-known)) in the ffap-machine-p function and traced it. It seems to return ping without any change. I'm overriding it with let... is the static scope causing the problem? Or is it because the method of calling the function is a bit special? At any rate, I tried changing it to (ffap-machine-p-known . 'accept) to work around it.

[thierryvolpiatto]

ncaq @.***> writes:

I noticed this problem today. I have the exact same problem. The version of helm is 20230129. The version of Emacs is GNU Emacs 28.2.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2023-02-06. I rewrote (t ffap-machine-p-known) to (t (print ffap-machine-p-known)) in the ffap-machine-p function and traced it. It seems to return ping without any change. I'm overriding it with let... is the static scope causing the problem? Or is it because the method of calling the function is a bit special? At any rate, I tried changing it to (ffap-machine-p-known . 'accept) to work around it.

Helm is already binding ffap-machine-p-known to 'accept' so you should not have to do this. Can you describe exactly what you are doing when this happen (also in which buffer are you and what you have at point).

Thanks.

-- Thierry

[ncaq]

1. I modify ffap-machine-p, 1443 line of ffap.el, (t ffap-machine-p-known) -> (t (print ffap-machine-p-known)).
2. I confirm ffap-machine-p-known of global value is ping.
3. I open text file below.

example.com

4. I execute C-x b as switch-to-buffer with enable helm minor mode on domain text.
5. Emacs display Pinging example.com (Commercial)..., and helm do not execute.
6. Emacs Message ping, not accept

I confirm helm-guess-filename-at-point let ((ffap-machine-p-known 'accept)), And I get backtrace, helm-guess-filename-at-point is in backtrace. However, ffap-machine-p-known is ping.

I'm sure I can rewrite here even if I use lexical scope...I couldn't figure out the cause. Is run-hook-with-args-until-success doing something special?

[thierryvolpiatto]

Please give me an example where you modify nothing in emacs source files, and you tell me what do you have at point e.g.:

In a text file with "init.as" at point launch helm-find-files or whatever helm command. What is happening?

Thanks.

ncaq @.***> writes:

1. I modify ffap-machine-p, 1443 line of ffap.el, (t ffap-machine-p-known) -> (t (print ffap-machine-p-known)).

Please don't do that.

2. I confirm ffap-machine-p-known of global value is ping. 3. I open text file below.

example.com

What is this? I can't open it, just show the string you have at point.

4. I execute C-x b as switch-to-buffer with enable helm minor mode on domain text.
5. Emacs display Pinging example.com (Commercial)..., and helm do not execute.
6. Emacs Message ping, not accept

I confirm helm-guess-filename-at-point

AFAIK, the bug is not triggered by this.

let ((ffap-machine-p-known 'accept)), And I get backtrace, helm-guess-filename-at-point is in backtrace. However, ffap-machine-p-known is ping.

I'm sure I can rewrite here even if I use lexical scope...I couldn't figure out the cause. Is run-hook-with-args-until-success doing something special?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: @.***>

-- Thierry

[ncaq]

I will try the minimum reproduction setting next time.

Please don't do that.

This happened without doing this. Then I realized the problem, and this was just to trace the variable.

What is this? I can't open it, just show the string you have at point.

My apologies for the lack of explanation. This meant to open a text file that just contains example.com.

[thierryvolpiatto]

ncaq @.***> writes:

1. ( ) text/plain (*) text/html

I will try the minimum reproduction setting next time.

Please don't do that.

This happened without doing this. Then I realized the problem, and this was just to trace the variable.

What is this? I can't open it, just show the string you have at point.

My apologies for the lack of explanation. This meant to open a text file that just contains example.com.

Thanks, I couldn't reproduce with example.com at point and C-x b or whatever command. Please try to reproduce from emacs-helm.sh.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: @.***>

-- Thierry